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•Volume  1 contains  the  System  Description  of  the  Integrated  Engine 
Instrument  System  (lEIS) . In  a ’effort  to  anticipate  the  needs  of  the 
fll^t  crew  and  maintenance  personnel  in  the  1980'*85  timeframe,  studies 
were  conducted  during  the  past  five  years  to  examine  engine  parameter 
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definition  and  selection,  sensor  analysis,  engine  cycles,  engine  modeling, 
mission  analysis,  data  trending,  electronic  fuel  control,  analog  subsystems 
for  vibration  and  turbine  blade  monitoring,  display  engineering,  fault 
isolation  techniques  and  human  factors.  The  resulting  baseline  lEIS  in- 
corporates a variety  of  disciplines,  including  engine  operation  analysis, 
computers,  multipurpose  displays,  data  bus  techniques,  and  data  recording. 
Deck  Launched  Intercept  and  Subsonic  Surface  Surveillance  missions  were 
selected  as  typical  applications  for  lEIS.  — 

X 

System  user  cost/benefit  analysis  and  fault  detection  criteria  presented 
in  qualitative  terms  supplement  specific  system  goals,  such  as  system 
accuracy  {±27,  including  sensors) , probability  of  false  alarm  on  the 
maintenance  status  indicator  (.0005),  self-test  coverage  (to  a .98  con- 
fidence level)  and  system  failure  rate  (4000  hours  (MTBF) . 

A central  data  bus,  interfacing  the  Electronic  Engine  Control  (EEC),  the 
Data  Management  Unit  (DMU) , the  display  processor,  the  data  processor, 
the  maintenance  status  indicators , the  keyboard  and  the  maintenance 
recorder,  requires  a relatively  low  transmission  speed  of  40  KBPS.  This 
bus  will  also  interface  with  other  aircraft  data  busses  and  will  probably 
conform  to  M1L'STD-1SS3  type  command  response  configuration. 

Flow  charts  show  how  lEIS  software  would  monitor  four  aircraft  operation 
modes,  prestart,  start,  in-use,  and  shutdown,  to  present  engine  condition 
and  initiate  corrective  action  upon  fault  detection. 

Computer  processor  and  memory  requirements  necessary  to  implement  the  lEI 
Operating  System  and  store  the  average  engine  model  are  shown  to  be  met 
by  a 32  bit  word  and  a 44K  word  memory. 

Display  engineering  concepts  for  lEIS  have  been  developed,  evaluated  in 
human  factors  studies  of  pilot  reaction,  and  modified  to  reflect  the 
optimum  display  techniques. 

Volume  II  contains  four  appendices  which  document  the  results  of  Phase  V 
investigations  in  engine  modeling,  display  human  factors  engineering  and 
instrumentation  requirements. 
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This  report  represents  the  Final  Report  for  Phase  V of  the  Integrated 
Engine  Instrument  System  (lEIS)  Program.  The  work  was  performed  by  General  Electric 
Company  on  contract  number  N62269-75-C-0359.  The  Naval  Air  Systems  Command  (NAVAIR 
SYSCOM) , Washington,  D.C.,  sponsored  the  work  and  provided  support  through  Messers. 

G.  Tsaparas  Air-340D  and  R.  Rank  Air-53351A.  Naval  Air  Development  Center,  Warminster, 
Pennsylvania,  administered  the  contract. 

Mr.  W.  G.  Cole,  AVTD  NADC,  has  been  the  Naval  Project  Engineer  for  this 
effort.  His  management,  Messrs.  K.  Priest,  V.  A.  Frietag,  and  E.  Rickner,  provided 
guidance.  Mr.  W.  Brietmaier  provided  assistance  in  the  Human  Factors  efforts  with 
guidance  from  his  manager,  Dr.  Hitchcock.  Their  efforts  in  leading  and  monitoring 
this  program  are  appreciated. 

General  Electric  Company  has  utilized  four  different  organizations  in 
the  execution  of  the  Phase  V portion  of  the  lEIS  program.  Mr.  R.  L.  Skovholt,  acting 
as  Program  Manager,  Mr.  W.  S.  Little,  who  prepared  the  technical  summary  and  coordinated 
the  technical  activities,  and  Mr.  C.  E.  Buzzell  who  performed  the  sensor  analysis  task, 
are  from  Aerospace  Instruments  and  Product  Support  Department,  Wilmington,  Massachusetts. 
Messers.  W.  A.  Doerle  and  R.  B.  Cooper  of  Ordnance  Systems  Department,  Pittsfield, 
Massachusetts,  performed  the  human  factor  tasks.  Messrs.  M.  Fine  and  R.  E.  Glusick 
of  Electronics  Laboratories,  Syracuse,  New  York,  performed  the  display  hardware  support 
task.  Messers,  H.  L.  McManus,  Jr.  and  I.  E.  Marvin  from  the  Aircraft  Engine  Group, 
Evendale,  Ohio,  performed  the  engine  conditioning  monitoring  work. 
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Introduction 


Volume  I (System  Technical  Summary) 

Volume  I is  a System  Technical  Summary  of  the  Integrated 
Engine  Instrument  System  (lEIS).  The  conclusions  and  recommendations  of  the 
key  investigations  conducted  during  the  five  phases  of  exploratory  development 
of  lEIS  are  summarized.  Because  of  the  duration  of  the  investigations  and  the 
variety  of  disciplines  involved,  the  key  results  are  contained  in  final  reports 
published  over  a six  year  period. 

Section  2.0  delineates  leading  particulars  of  the  lEIS,  including 
goals,  benefits,  costs,  accuracy,  failure  rate  and  system  description.  Section  3.0 
identifies  baseline  requirements  for  each  identifiable  lEIS  subsystem.  Section 
4.0  is  devoted  to  the  summary  of  human  factors  investigations  which  have  been  a 
prominent  part  of  the  previous  four  phases.  Section  5.0  presents  conclusions 
and  recommendations  for  future  development  activities  which  would  improve  the 
performance  of  the  lEIS. 

The  System  Technical  Summary  is  not  intended  to  detail  any  or  all  of  the 
previous  investigations.  Rather,  pertinent  data  for  each  subsystem  such  as 
interface  definitions,  performance  requirements,  and  significant  trade  study 
results,  which  collectively  form  a baseline  system  definition,  are  assembled. 

Since  many  of  the  subsystems  identified  will  eventually  be  incorporated  in 
aircraft  systems,  defining  the  subsystem  interfaces  is  emphasized.  Frequent 
references  to  the  source  of  the  data  presented  enable  the  reader  to  refer  to 
the  final  reports  of  the  five  phases  for  details  of  the  investigation  leading 
to  the  subsystem  characteristics  described  herein. 

The  system  characteristics  are  generic  in  nature  because  the  actual 
implementation  will  be  defined  only  for  specific  applications  and  will  vary 


r 

f 

I 


depending  on  the  application.  However,  the  system  complexity  required  to  i 

implement  the  lEIS  concepts  is  represented.  In  addition,  many  characteristics 
may  be  directly  applied  to  a specific  system.  Summaries  of  the  key 
investigations  conducted  in  each  phase  are  given  below. 

During  Phase  I,  preliminary  investigations  in  the  areas  of  engine 
parameter  analysis,  energy  management,  thrust  measurement,  sensor  requirements, 
data  management  and  processing,  and  display  and  human  factors  requirements  were 

undertaken.  A display  generator  was  designed,  fabricated,  and  interfaced  with 
an  off-the-shelf  display  terminal. 

During  Phase  II,  investigations  of  display  and  human  factors  requirements 
were  conducted.  Specifically,  display  information  and  presentation  were 
given  attention.  The  G.E.  Aircraft  Engine  Group,  Evendale,  Ohio  and  Navy 
pilot  personnel  aided  in  this  effort.  Also,  a major  effort  was  undertaken 
during  this  phase  to  design  appropriate  hardware  to  provide  dynamic  display 
evaluation.  A keyboard  and  Interface  box  achieved  this  capability  without 
the  need  of  a dedicated  computer. 

During  Phase  III,  more  detailed  investigations  in  aircraft  engine 
performance  monitoring,  system  design,  and  display  engineering  were  conducted. 

In  the  area  of  engine  analysis,  key  investigations  included  parameter  | 

determination,  engine  cycle  analysis,  engine  modeling,  and  mission  analysis. 

Deck  launched  intercept  and  subsonic  surveillance  missions  were  selected  for 
a detailed  analysis  of  requirements.  Concurrent  with  the  engine  analysis, 
the  lEIS  system  design  activity,  including  investigations  in  specific  areas 
and  a technological  survey,  was  undertaken  to  insure  the  appropriateness  of 
the  design  for  the  intended  timeframe.  Specifically,  the  requirements  for 

i 
i 

J 


1 


1-2 


signal  conditioning,  the  data  management  unit,  data  transmission,  computer 
hardware  and  software,  and  the  data  recorder  were  established.  In  addition 
to  these  system  requirement  studies,  human  factors  evaluations  of  displays 
were  conducted.  Pilot  reactions  were  obtained.  The  results  were  analysed 
and  modifications  to  the  display  formats  were  recommended. 

During  Phase  IV,  work  performed  included  system  design  studies 
necessary  to  relate  lEIS  requirements  to  the  All  Applications  Digital  Conqjuter 
(AADC) , display  hardware  modifications  to  make  it  more  flexible,  a display 
media  technology  Investigation,  and  a continuation  of  human  factors  display 
evaluations  using  the  lEIS  display  demonstrator. 

During  Phase  V,  the  work  performed  included  a review  of  the 
engine  monitoring  concepts  developed  in  Phase  III,  a feasibility  study  of 
transient  engine  condition  monitoring,  a definition  of  sensor  characteristics 
(present  and  projected)  in  matrix  form,  a human  factors  display  evaluation  in 
a simulated  AIDS  cockpit,  and  the  preparation  of  this  System  Technical  Summary. 
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Volume  II  (Current  Effort  Results) 

Volume  II  documents  in  the  form  of  appendices  the  results  of 
the  Phase  V tasks  in  the  areas  of  engine  condition  monitoring;  display 
engineering;^  and  instrumentation  and  sensor  definitions. 

Appendix  A is  a report  on  a Transient  Engine  Condition  Monitoring 
Feasibility  Study.  The  lEIS  engine  model  defined  during  Phase  III  is  a steady- 
state  model  which  does  not  monitor  the  engine  during  transients.  The  purpose 
of  this  study  was  to  establish  the  feasibility  of  including  a transient  capa- 
bility in  this  model  to  allow  continuous  engine  monitoring. 

Appendix  B is  a report  on  a limited  study  to  identify  ways  to 
improve  the  steady-state  engine  model.  Specifically,  conclusions  regarding 
results  of  on-going  programs,  such  as  the  Advanced  Engine  Monitoring  Evaluation 
System  (ADEMS)  and  the  LM2500  condition  monitoring  program*  were  reviewed  for 
application  to  lEIS. 

Appendix  C describes  the  Phase  V display  engineering  effort, 
which  is  an  extension  of  the  work  accomplished  in  the  previous  four  phases. 

Display  formats  have  been  developed  further  and  subjected  to  evaluation  by 
experienced  Navy  pilots  in  a simulated  cockpit  environment.  Both  the  clarity 
and  the  appropriateness  of  the  information  displayed,  as  well  as  the  need  for 
information  not  displayed,  were  discussed  between  the  narrator  and  the  pilot 
subjects  preceeding  interactive  scenario  exercises.  Evaluators  recorded  pilot 
responses  during  and  after  each  exercise.  Standard  engine  and  flight  operations, 
attack  procedures,  range  cruise  plots,  and  simulated  malfunctions  (including  restart) 
constituted  the  scenario. 

^The  Phase  V contract  also  provided  for  limited  support  of  the 
lEIS  display  hardware.  The  tape  reader  for  the  equipment  has  failed  and 
cannot  be  repaired.  Various  options  are  being  investigated. 
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Appendix  D contains  a survey  of  presently  available  sensors 
and  standard  specifications  summarized  In  a sensor  matrix.  The  areas  requiring 
additional  development  to  meet  the  future  lEIS  requirements  are  also  indicated. 
For  the  pre  1980  time-frame,  standard  engine  sensors  are  considered  to  be 
technically  limited  for  many  reasons.  First,  sensor  response  times  are 
generally  inadequate  to  meet  transient  engine  analysis  requirements.  Secondly, 
sensor  outputs  are  not  standardized  and  require  special  conversion,  conditioning, 
and  buffering.  Thirdly,  higher  performance  engines  push  operating  ambient 
conditions  beyond  the  limit  of  present  sensor  capabilities. 
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2.0 


lEIS  LEADING  PARTICULARS 


2.1  System  Goals 

2.1.1  System  User  Benefits 

An  Integrated  Engine  Instrumentation  System  can  be  Justified  as  a 
replacement  for  the  presently  used  collection  of  single-purpose  instruments  only 
if  user-related  benefits  are  achieved  by  the  change.  The  identifiable  benefit 
areas  are  as  follows: 

1.  Integrate  the  presentation  of  engine  instrumentation  data  to  such 
an  extent  that: 

a)  Cockpit  display  space  can  be  released  for  more  directly 
mission-related  information. 

b)  Comprehension  and  visibility  of  the  engine  information  can 

be  improved. 

c)  Crew  training  costs  can  be  reduced. 

d)  Chances  of  unintentional  operation  of  the  engine  beyond  its 
recommended  range  of  use  can  be  reduced  with  consequent  increase  in  engine  life- 
time, reduced  maintenance  costs  and  the  implementation  of  maintenance  by  need. 

e)  Crew  efficiency  can  be  increased  by  reducing  the  time  devoted 
to  monitoring  engine  Instruments  and  fuel  expenditure. 

2.  Increase  the  amount  of  analysis  performed  on  the  engine  data  so 

as  to: 

a)  Decrease  total  engine  maintenance  costs  by  requiring  mainten- 
ance actions  oi\ly  on  an  as-needed  basis  rather  than  on  a fixed  schedule. 

b)  Decrease  the  rate  of  occurrence  of  in-flight  engine  failure 

by  extrapolation  of  observed  changes  in  significant  measures  of  engine  performance 
and  taking  the  maintenance  action  indicated  prior  to  degradation  to  unservlcable 
level . 
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I c)  Decrease  the  rate  of  occurrence  of  in-flight  engine  failure 

by  maintaining  accurate  individual  logs  of  service  time  of  all  engine  components 
I and  using  these  to  require  replacement  prior  to  wear-out. 

2.1.2  System  Costs  to  User 

> The  user  benefits  enumerated  could  be  offset  by  costs  incurred  because 

I of  inadequate  performance  of  the  engine  instrumentation  system  in  any  of  the 

following  particulars: 

I 1.  Excessive  lags  in  instrumentation  response  times  resulting  in 

decreased  efficiency  of  engine  use. 

I 2.  Generation  of  inaccurate  data  resulting  in  improper  crew  actions 

■ or  unneeded  maintenance  actions. 

3.  Generation  of  false  alarms  requiring  unnecessary  crew  attention 

I or  maintenance  checking. 

4.  Undetected  instrumentation  system  faults  producing  misleading 

I system  outputs. 

5.  Frequent  failure  of  the  instrumentation  system  hanq>ering  or  halting 

V operational  use  of  the  aircraft  or  raising  the  maintenance  costs. 

m 6.  Excessive  instrument  system  repair  time  reducing  the  operational 

availability  of  the  aircraft. 

I 7.  Excessive  crew  actions  required  to  operate  the  instrumentation  system. 

8.  Special  flight  regimes  or  maneuvers  required  to  operate  or  call- 
I brate  instrumentation  system. 

Ideally  one  should  be  able  to  quantify  these  benefits  and  associated 

■ costs  and  arrive  at  an  economically  optimum  system  specification  such  that  the  excess 

■ of  benefits  returned  after  ownership  costs  incurred  would  provide  an  acceptable 
return  on  the  Investment  required  to  procure  the  system.  Such  a model,  rationalized 

I on  purely  economic  considerations,  has  not  been  attempted  in  this  study.  Instead, 
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we  have  attempted  to  arrive  at  a system  model  that  would  provide  the  benefits 
listed  (with  some  reservations  regarding  the  possibilities  for  computing  all 
optimum  energy  management  control  strategies)  attainable  Instrumentation  system 
performance  which  are  attainable  and  represent  a reasonable  compromise  between 
ownership  costs  and  system  procurement  costs. 

2.1.3  Engine  Fault  Detection  Criteria  Summarized  In  Qualitative  Terms 
The  engine  instrumentation  system  will  detect  faults  in  engine  or 

engine  controllers  that  result  in  a five  percent  or  greater  reduction  in  gross 
thrust  produced  relative  to  the  generic  engine  under  the  same  operating  condition. 

The  instrumentation  system  will  detect  engine  faults  that  result  in 
a ten  percent  or  greater  increase  in  fuel  consumption  (relative  to  the  generic 
engine  model  under  Che  same  operating  conditions). 

The  instrumentation  system  will  detect  engine  lubrication  faults 

V 

which  will,  If  uncorrected,  result  In  excessive  engine  wear. 

The  instrumentation  system  will  detect  any  condition  sufficiently 
hazardous  as  to  require  Inmedlate  engine  shutdown. 

2.1.4  False  Alarm  Rate 

The  probability  of  the  engine  instrument  system  activating  a false 
maintenance  status  indicator  shall  be  less  chan  .0005. 

2.1.5  System  Latency 

The  maximum  delay  in  direct  presentation  of  engine  sensor  data  shall 
not  exceed  two  seconds. 

The  maximum  delay  in  presentation  of  computed  data  shall  not  exceed 
three  seconds. 

The  maximum  discrepancy  between  time  labeled  recorded  data  and  true 
time  of  acquisition  shall  not  exceed  two  seconds. 
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2.1.6  System  Accuracy 

I The  maximum  error  from  all  sources  in  any  displayed  or  recorded 

numeric  data  shall  not  exceed  ±2%. 

I The  total  error  introduced  by  the  instrumentation  system  (as  distinct 

from  the  measuring  sensors)  shall  not  exceed  0.5%. 

1 The  rate  of  occurrence  of  undetectable  errors  in  recorded  digital 

■ data  introduced  by  flaws  in  the  recording  process  or  medium  shall  not  exceed 
one  bit  in  10^^. 

I 2.1.7  Self-Check  and  Built-In  Test  Coverage 

Successful  completion  of  the  System  Self-Test  Program  shall  assure  a 

I fully  operational  engine  instrumentation  system  at  a .98  confidence  level. 

2.1.8  Redundancy 

■ The  system  configuration  shall  be  such  that,  when  utilizing  the  back- 

■ up  reserves  of  interfacing  systems  as  well  as  internal  system  redundancies,  the 
system  shall  be  fail  operational  for  single  failure  conditions. 

I Sensor  failures  will  be  minimized  by  altering  the  programmed  models 

to  produce  the  datum  of  the  failed  sensor. 

I Analog  converter  failures  will  be  minimized  by  using  reserve  channels 

■ in  the  engine  controller  A/D  converter. 

Data  transmission  failures  will  be  minimized  by  redundancy  of  the 
i I Data  Bus  Transmission  System. 

Processor,  memory  and  recorder  failures  will  be  minimized  by  redundancy 

I within  the  AADC  complex. 

Display  failures  will  be  minimized  by  reciprocal  sharing  of  the  Master 

I Monitor  Unit  Display  of  the  AIDS. 

_ 2.1.9  Mean-Time-To-Repair 

Except  for  replacement  of  engine  mounted  sensors,  the  lEIS  MTTR  shall 

I be  one-half  hour  for  technicians  of  normal  skill  levels. 

\ 
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2.1.10 


System  Failure  Rates 


Apart  from  engine  mounted  sensors,  the  system  MTBF  shall  exceed 
4,000  hours. 

2.2  System  Description 

2.2.1  Scope 

This  description  summarizes  the  performance  requirements  for  the  lEIS. 
The  system  described  is  intended  to  supply  the  engine  instrumentation,  performance 
monitoring,  analysis,  recording  and  real  time  display  of  engine  operation  for 
application  to  future  Naval  aircraft. 

2.2.2  System  Functions 

The  lEIS  provides  the  aircraft  pilot  a single,  simplified  display  of 
engine  performance  information  on  a management-by-exception  basis.  The  lEIS 
provides  the  pilot  a visual  presentation  of  present  or  predictable  engine  mal- 
function with  associated  advisory  information.  The  lEIS  will  respond  to  operator 
keyset  commands  to  produce  a visual  presentation  of  selected  engine  parameters, 
fuel  reserves  and  the  flight  control  actions  to  achieve  the  best  practicable  fuel 
and  time  utilization.  During  specific  engine  operating  regimes  and  at  scheduled 
times  during  each  flight,  the  lElS  collects,  formats  and  records  engine  sensor  data 
as  needed  for  off-line,  ground-based  "long-term  trending"  analysis  to  detect  slowly 
occurring  changes  In  engine  performance  capabilities  and  to  predict  the  times  at 
which  specific  engine  maintenance  actions  should  be  taken.  The  lEIS  automatically 
maintains  a log  of  engine  service  time  by  component.  The  lEIS  analysis  of  engine 
performance  detects  operating  conditions  indicating  maintenance  actions  as  these 
reach  the  polnt-of-need  while  in  operation.  The  lEIS  automatically  compares  fuel 
consumption  to  pre-flight  plan.  The  lEIS  maintains  a record  of  all  engine  sensor 
readings  during  engine  operating  periods  and  produces  a permanent  record  of  this 
operating  history  in  the  event  an  engine  malfunction  is  detected.  The  record 
produced  is  augmented  by  a two-minute  extension  of  the  engine  operation  data 
beyond  the  instant  at  which  the  malfunction  was  detected. 


2.2.3  Syscem  Inputs 

Engine (s)  Sensor  Inputs 

The  approximately  65  inputs  (per-engine)  to  the  lEIS  from  engine  sensors, 
signal  processors  and  engine  controllers  are  enumerated  and  described  in  Section 
3.2.1  of  this  report. 

Data  Bus  Inputs 

The  lEIS  utilizes  air-data  inputs  which  are  assumed  to  be  distributed 
within  the  aircraft  via  an  aircraft  data  bus  system.  These  inputs  include  the  following: 

• Airspeed 

• A/C  Geographic  Location  Coordinates 

e A/C  Clock  Time  Reading 

• A/C  Altitude 

Ground  Support  Equipment  Inputs 

The  lEIS  receives  and  responds  to  data  inputs  from  ground  support 
equipment  for  the  following: 

1.  Commands  to  perform  and  report  lEIS  readiness  tests. 

2.  Modifications  to  the  lEIS  engine  service  time  logs  occasioned 
by  replacement  of  engine  components. 

3.  Maintenance  crew  "sign  off"  of  maintenance  actions  detected  by 

the  lEIS. 

4.  Modifications  to  the  lEIS  computer  engine  models  resulting  from 
revisions  of  the  characterization  of  the  engine  as  a consequence  of  maintenance 
actions  or  analysis  of  fleet-wide  records  of  performance  of  the  same  engine  type. 

5.  Calibration  data  for  any  sensors  replaced  as  a maintenance  action. 

Pilot  Inputs 

The  lEIS  receives  control  information  from  the  pilot  via  a keyset  further 


described  in  Section  3.7  of  this  summary. 


2.2.4  System  Outputs 

Data  Recording 

An  individual  "engine  performance  record"  consists  of  a single  reading 
of  all  of  the  engine  sensor  data  and  the  data  defining  the  flight  conditions 
under  which  it  was  taken.  During  engine  operation,  all  sensor  outputs  are  sampled 
four  times  per  second  and  transferred  into  the  core  memory  of  the  data  processor. 

Once  each  second,  the  processor  is  programmed  to  convert  these  data  (four  readings 
for  each  sensor)  from  sensor  readings  to  the  corresponding  physical  unite  as 
determined  by  the  scale  factors,  biases  and  calibration  curves  of  the  sensor. 

The  mean  and  deviation  of  the  four  samples  taken  from  each  sensor  are  then  deter- 
mined. The  average  value  of  the  sensor  output  (in  physical  units)  is  the  datum 
for  that  sensor  appearing  in  the  engine  performance  record.  The  engine  performance 
record  is  made  at  engine  start,  at  take-off  and  at  approximately  20  equally  separated 
time  intervals  during  the  flight.  To  be  of  greatest  use  for  ground-based  "long- 
term trending"  of  the  engine  performance,  these  data  must  be  taken  under  stable 
engine  operating  conaitions  which  are  defined  as  follows: 

• Engine  rotation  speed  has  not  deviated  by  more  than  "A"  RFM  during 
the  past  minute  of  engine  operation. 

• Total  inlet  temperature  has  not  deviated  by  more  than  "B"  degrees 
during  the  past  minute  of  engine  operation. 

• Total  inlet  pressure  has  not  deviated  by  more  than  "C"  psi  during 
the  past  minute  of  engine  operation. 

A permanent  record  of  every  other  one  second  average  of  all  engine 
sensor  readings  extending  over  a five-minute  interval  spanning  the  moment  at  which 
an  engine  malfunction  was  detected  is  produced  by  the  lEIS.  The  record  thus  contains 
130  readings  of  each  of  the  65  sensors.  During  stable  engine  operation,  the  sensor 
readings  are  used  as  input  to  computations  of  several  indices  of  engine  performance. 
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such  as  the  thermodynamic  efficiencies  of  rotating  components  and  correct  positions 
of  servoed  controls.  Limits  on  these  derived  quantities  are  known  from  the 
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computer  model  of  the  characterized  engine  for  whatever  operating  conditions  exist. 

i 

Other  sensor  readings  (lube  quantity,  for  example)  are  subject  to  fixed  limits 
whatever  the  operating  conditions  of  the  engine.  Each  data  set  (every  second) 
taken  under  conditions  satisfying  the  criteria  for  stable  engine  operation  is 
analyzed  for  limit  exceedance  of  any  of  the  items  shown  in  Table  2.2-1. 

If  any  of  these  parameters  exceed  their  allowable  limits  on  two  suc- 
cessive averaging  intervals,  a malfunction  is  assumed  to  have  occurred  and  the 

loop  record  dump  is  performed. 

\ 

Maintenance  Status  Indicator 

Maintenance  Status  Indicator  counters  can  be  displayed  as  output  of 
lEIS  in  the  form  of  a set  of  indicators,  each  corresponding  to  one  of  the  entries 
in  Table  2.2-1.  They  are  incremented  by  the  computer  whenever  an  out-of-limits 
malfunction  involving  the  corresponding  engine  parameter  is  detected.  The  counter 
is  cleared  by  the  maintenance  crew  after  correcting  the  conditions  leading  to  the 
malfunction.  Physically,  the  summary  maintenance  status  indicator  is  in  the  form 
of  an  annunciator  readily  available  from  outside  the  A/C.  The  summary  maintenance 
status  indicator  is  set  when  any  one  or  more  of  the  individual  indicators  are  set. 

MUX  Outputs 

Sunmary  engine  status  and  fuel  status  will  be  transmitted  by  the  lEIS 
to  other  aircraft  systems  via  the  Aircraft  Central  Data  Bus  System. 

Pilot  Display 

The  principal  lEIS  output  is  to  the  pilot's  display.  The  lEIS  Display 
provides  the  pilot  with  engine  status,  engine  performance,  aircraft  (AC)  performance, 
and  energy  management  information.  This  information  is  presented  to  the  pilot  through 
different  display  formats.  A discussion  of  the  techniques  of  the  presentation  of 
the  information  is  contained  in  Section  4.0. 
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TABLE  2.2-1  MONITORED  ENGINE  PERFORMANCE  PARAMETERS 
FOR  MAINTENANCE  STATUS  INDICATION 
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Operational  Phases 

The  lEIS  functionsdiffer  among  the  following  flight  phases: 

• Engine  Pre-Start 

• Engine  Start 

• Engine  Operating 

• Engine  Shutdown 
Functions  Performed  During  Pre-Start 

1.  lEIS  self-test  and  a check  for  the  absence  of  maintenance  status  counters. 

2.  Input  current  sensor  readings  as  single  entry  in  engine  performance 
record  and  loop  record. 

3.  Monitor  engine  check  list  and  display  items  (as  English  text)  not 

satisfied. 

4.  Input  AGE  data  modifying  service  time  log. 

5.  Input  data  (via  Keyset)  on  fuel  expenditure  plan  for  flight. 

6.  Monitor  for  application  of  starter  power. 

Functions  Performed  During  Engine  Start 

1.  Output  pre-start  performance  record. 

2.  Begin  data  collection  for  loop  record. 

3.  Log  start  time  (from  first  application  of  starter  power  to 
core-spool  break-away) . 

4.  Display  elapsed  start  time. 

5.  Monitor  engine  malfunction  for  the  following: 

Lube  Pump  Performance 
Starter  Position 
IGV  Position 
Nozzle  Area 
Fan  Speed 
Core  Speed 
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Main  Fuel  Flow 


Mass  Unbalance  1,  2 
Lube  Level 

Fuel  Filter  Delta  Pressure 
Lube  Flow 
, Lube  Quality 

Scavenge  Filter  Delta  Pressure 

Functions  Performed  During  Engine  Operation 

The  complete  set  of  lEIS  functions  enumerated  in  Section  2.2.2  is 
performed  during  those  times  the  engine  is  in  operation. 

Functions  Performed  At  Engine  Shutdown 

At  engine  shutdown,  the  lEIS  displays  the  equivalent  of  the  MSI  display, 
computes  and  posts  the  flight  time  increment  to  the  service  time  record 
for  all  engine  components,  and  monitors  pilot  keyset  requests. 


I 
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3.0 


SYSTEM  REQUIREMENTS 


Through  a comprehensive  program  of  exploratory  development  over  the 
past  six  years  the  lEIS  system  concept  has  evolved.  The  program  plan  (see 
Figure  3.0-l)  developed  in  Phase  I has  basically  been  followed.  During  Phase  I 
a first  cut  at  system  requirements  was  made  and  more  detailed  studies  were  under- 
taken in  later  phases  when  a need  was  identified. 

Detailed  requirements  of  the  baseline  lEIS  system  defined  in  these 
exploratory  development  programs  are  presented  in  the  following  sections  for 
each  identifiable  subsystem  of  lEIS. 

3.1  lEIS  System  Block  Diagram 

The  block  diagram  of  the  Integrated  Engine  Instrument  System  is  shown 
in  Figure  3.1-1.  Each  block  represents  a subsystem.  The  lElS  processor  receives 
inputs  from  the  Electronic  Engine  Controls  (EEC) , the  Data  Management  Units  (DMU) , 
and  the  lEIS  keyboard.  In  addition,  various  status  and  energy  management  inputs 
are  received  from  the  aircraft  interface.  The  lEIS  processor  will  provide  data 
to  the  Data  Recorder  and  the  Displays. 

The  engine  sensors  are  divided  into  the  two  following  groups:  those 

which  primarily  service  the  Electronic  Engine  Controllers  and  those  which  are 
devoted  exclusively  to  the  lEIS  Data  Management  Unit.  Some  sensor  signals  must 
interface  with  both  users.  Both  the  EEC’s  and  DMU's  convert  the  analog  sensor  data 
to  digital  form  for  transmission  over  the  Data  Bus  to  the  lEIS  processor. 

The  Data  Recorder  stores  both  routine  long  term  trend  data  and  the 
five  minute  loop  record  dumps.  The  routine  data  is  recorded  at  given  time  Intervals 
depending  upon  mission  length  and  engine  stability.  Routine  data  is  also  taken  at 
squat  (weight  on  wheels)  switch  activation  and  during  the  take-off  (a  period  of 
high  engine  stress).  The  five-minute  loop  record  dumps  are  initiated  by  an  engine 
malfunction  and  consist  of  three  minutes  of  data  prior  to  the  event  and  two  minutes 
after  the  event.  The  loop  record  provides  a history  for  subsequent  analysis  on 
the  ground. 
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FIQ.  3.0-1 
PROGRAM  PLAN 


The  Maintenance  Status  Indicator  will  serve  as  a maintenance -needed 


annunciator  to  the  ground  crew.  This  indicator  will  result  in  the  removal  of 
the  aircraft  from  active  service  for  maintenance  action.  During  ground  main- 
tenance or  at  the  end  of  the  flight  day,  the  Data  Recorder  should  be  dumped  to 
the  ground  computer.  These  system  elements  are  discussed  in  more  detail  in  the 
following  sections. 

Since  the  lElS  Aircraft  will  include  an  Electronic  Engine  Control,  the 
lElS  processor  will  make  use  of  those  engine  parameters  required  by  lElS  which  have 
been  converted  to  a digital  format  by  the  EEC.  This  scheme  will  relieve  the  I^IU  of 
some  analog  conversion  and  signal  conditioning  tasks,  while  allowing  only  the  prime 
subsystems  (the  EEC  in  this  case)  to  interface  with  the  engine  sensors.  Thus,  the 
sensor  is  loaded  by  only  one  signal  conditioning  circuit.  One  EEC  unit  per  engine, 
has  been  assumed  for  reliability  reasons. 

Separate  mu's  have  also  been  specified.  The  conversion  channel  will 
mount  close  to  the  applicable  sensor,  thereby  minimizing  noise,  interference,  and 
erroneous  conversions.  Compared  with  one  central  DMU,  the  federated  system  should 
improve  reliability  and  flexibility  and  result  in  only  minor  volume,  power  and 
weight  penalties. 

3.2  Input  Parameters 

3.2.1  Parameters /Sources 

The  parameters  acquired  by  the  lElS  system  are  listed  in  Figures  3.2-1, 
3.2-2  and  3.2-3.  Figure  3.2-1  gives  those  parameters  which  are  aquired  from  the  EEC. 
This  list  basically  represents  those  parameters  which  the  engine  controller  would 
use  out  of  the  total  instrumentation  requirements.  Rather  than  repeating  digital 
conversion,  lEIS  would  interface  with  the  EEC  via  its  data  bus  to  obtain  the  para- 
meter information  in  digital  form.  The  alphanumerics  in  the  "NAME"  column  are 
derived  from  the  ARP681B  standard  and  would  not  necessarily  be  used  on  the  lElS 
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DESCRIPTION 

NAME 

RANGE 

UNITS 

REPEATABILITY 
{+  % F.S.) 

ENGINE  INLET  TOTAL  PRESS- 

PI 

O-kAO 

PSIA 

2 

ENGINE  INLET  TOTAL  TEMP. 

T1 

-6S*‘*00 

Of 

1 

A/B  FUEL  FLOW 

WF6 

0+70 

KPPH 

1 

LOW  PRESS.  COMP.  ROTOR  SPEED 

XNL 

0+9 

krfm 

.1 

FAN  INLET  GUIDE  VANE  POS. 

BF 

-10-25 

o 

1 

HIGH  PRESS.  TURB.  BLADE  TEMP. 

TC 

600+2000 

Of 

1 

CORE  ENG.  ROTOR  SPEED 

XNH 

0+16 

KRPM 

.1 

MAIN  FUEL  FLOW 

WF36 

0+12 

KPPH 

1 

CORE  VARIABLE  STATOR  POS. 

BC 

-5+35 

o 

3 

JET  NOZZLE  THROAT  AREA 

AB 

600+1700 

SQ.  IN. 

1.5 

CORE  COMP.  INLET  TOTAL  PRESS. 

PT25 

0+50 

PSIA 

1 

FAN  DUCT  PRESS.  RATIO 

PDOS 

0+.2 

— 

5 

MAIN  FUEL  PUMP  DISC.  PRESS. 

PWFM 

0+1200 

PSIA 

1.5 

A/B  FUEL  MANIFOLD  PRESS. 

P6 

0+1200 

PSIA 

1 .5 

IGV  TORQUE  MOTOR  CURRENT 

BFTM 

+200 

MA 

1 

MAIN  FUEL  TMC 

WFMTM 

+200 

MA 

1 

A/B  FUEL  TMC 

WFRTM 

+200 

MA 

1 

A8  TMC 

A8TM 

+200 

MA 

1 

POWER  LEVER  ANGLE 

PLA 

0+130 

o 

- 

STALL  MARGIN 

STALL 

-25+50 

% 

- 

FIGURE  3.2-1 

ENGINE 

PARAMETERS  ACQUIRED 

FROM  EEC 

i 

1 


1 

r 


3-5 


W 


Description 

Name 

Range 

Units 

Repeatability 
(+  7.  F.S.) 

H.P.  Comp.  Inter.  Bleed  Flow 

WB27 

0+7 

PPS 

1 

H.P.  Comp.  Disch.  Bleed  Flow 

WB3 

0+7 

PPS 

1 

Anti-Ice  Flow 

WBAl 

On/Off 

— 

— 

H.P.  Rotor  Pwr.  Extraction 

HPX 

On/Off 

— 

— 

L.P.  Turb.  Disch.  Temp. 

T5 

-65+2000 

°F 

1 

Comp.  Exit  Total  Temp. 

T3 

-65+1200 

°F 

.5 

Comp.  Exit  Static  Press. 

PS3 

0+400 

PSU 

1 

Core  Comp.  Inlet  Total  Temp. 

T25 

-65+900 

°F 

1 

L.P.  Turb.  Inlet  Total  Press. 

P49 

0+100 

PSU 

1 

L.P.  Turb.  Inlet  Total  Temp. 

T49 

-65+2000 

°F 

1 

FOD  Flag  (2) 

FOD  F 

On/Off 

— 

— 

Scavenge  Temp.  (4) 

TLS1-TLS4 

-65+300 

°F 

1 

Scavenge  Press.  (4) 

PLS1-PLS4 

0+100 

PSI 

1 

Bearing  Condition  (2) 

BRG 

0+10 

— 

2 

Mass  Unbalance  (2) 

MUM 

0+10 

MILS 

2 

Oil  Level 

OL 

0+6 

GAL 

2 

Oil  Press. 

PL 

0+500 

PSU 

2 

Oil  Temp. 

TL 

-65+300 

°F 

1 

Oil  Quality 

QUALO 

0+100 

7, 

--- 

Oil  Flow 

WLO 

0+20 

GPM 

3 

Oil  Filter  Delta  Press. 

LFDP 

0+20 

PSI 

2 

Bearing  Race  Temp.  1 

BRGTl 

-65+350 

°F 

3 

Bearing  Race  Temp.  2 

BRGT2 

-65+350 

°F 

3 

Fuel  Filter  Delta  Press. 

FFDP 

0+100 

PSID 

2 

Hottest  Turb.  Blade  Temp. 

T4  MAX 

+600+2000 

°F 

1 

Hottest  Turb.  Blade  Position 

T4  MAX  P 

0+100 

°F 

— 

Coldest  Turb.  Blade  Temp. 

T4  MIN 

+600+2000 

°F 

1 

Coldest  Turb.  Blade  Position 

T4  MIN  P 

0+100 

°F 

--- 

FIGURE  3.2-2  - ENGINE  PARAMETERS  ACQUIRED  FROt  lEIS  SENSORS 
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DESCRIPTION 

NAME 

RANGE 

UNITS 

FREE  STREAM  STATIC  PRESS 

PAMB 

0+15 

PSIA 

HUMIDITY 

HUM 

0+100 

% 

WEATHER 

WHER 

RAIN,  SNOW 

ALTITUDE 

ALT 

0+70 

KFT 

MACH  NO. 

XM 

0+2.5 

- 

DATE 

DATE 

- 

MO/DAY/YR 

TIME 

TIME 

- 

HR/M  IN/SEC 

ELAPSED  RUN  TIME 

ERT 

- 

HR/MI N/SEC 

ENGINE  SERIAL  NO. 

ESN 

- 

- 

A/C  SERIAL  NO. 

ACSN 

- 

- 

AIR  FLOW  LIMIT  SWITCH 

ALS 

ON/OFF 

- 

SQUAT  SWITCH 

- 

ON/OFF 

- 

POSITION 

- 

- 

- 

ACCELERATION 

ACC 

- 

FT/SEC^ 

AIR  SPEED 

AS 

- 

KNOTS 

ANGLE  OF  ATTACK 

AOA 

- 

DEG 

FUEL  QUANTITY 

QF 

- 

LBS 

A/C  WEIGHT 

TOGW 

0+50 

KLBS 

A/C  STORES 

- 

- 

LBS 

A/C  G LIMITS 

• 

• 

G'S 

FIGURE  3.2-3 

DATA  ACQUIRED 

FROM  A/C  INTERFACE 

I 

L 
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display.  The  "Repeatability"  is  a sensor  specification  giving  lEIS  requirements 
on  the  ability  of  a sensor  to  repeatedly  measure  the  same  input  signal  level 
accurately.  This  specification  is  not  applicable  to  those  inputs  obtained  from 
the  EEC  or  the  airframe,  since  lEIS  is  not  accountable  for  the  sensors.  However, 
the  expectation  is  that  the  indicated  levels  will  be  met  through  close  Integration 
of  all  requirements.  Figure  3.2-2  lists  those  parameters  obtained  from  the  lEIS 
DMU.  Sensors  for  these  parameters  could  be  considered  part  of  lEIS.  The  EEC 
and  DMU  share  the  load  in  providing  the  necessary  engine  parameters,  while  the 
A/C  provides  certain  identification,  status  and  energy  management  inputs, 
parameters  listed  in  the  three  figures  are  the  result  of  evolutionajy^ study  and 
analysis  based  on  the  lEIS  concepts  of  condition  monitoring,  fatilt  isolation  and 
detection,  and  energy  management.  During  Phase  V the  engine  related  sensor 
characteristics  required  to  provide  the  parameters  listed  in  Figures  3.2-1  and 
3.2-2  were  established.  These  characteristics  are  defined  in  section  3.2.3. 

3.2.2  Parameter  Selection 

During  Phase  I a preliminary  set  of  parameters  was  selected  which  would 
provide  information  required  by  lEIS  to  determine  both  short  and  long  term  engine 
health.  Short  term  health  relates  to  those  parameters  which  would  be  displayed 
in  flight  if  they  exceed  a set  of  specified  limits.  These  and  additional  parameters 
would  also  be  monitored  for  fault  isolation  and  long  term  trending  purposes. 

The  selection  process  in  Phase  I analysed  the  basic  subsystems  of  a 
1980-85  attack  fighter  engine  to  determine  the  parameters  and  techniques  required 
to  perform  short  and  long  term  engine  condition  monitoring.  The  six  basic  subsystems 
considered  were  the  following: 

• Thermodynamic  Gas  Path 

• Lubrication 

• Fuel /Control 

• Hydraulic 

• Electrical 

• Mechanical  Integrity 
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The  analytical  tools  used  included  a steady  state,  engine  cycle 


computer  model  and  previously  obtained  data  from  simulation  activities  and/or  field 
experience.  These  basic  tools  were  utilized  to  determine  the  sensitivity  of  para- 
meters to  deterioration  of  engine  subsystem  components  which  would  result  in 

degradation  of  the  engine  performance.  From  this  work,  the  selection  of  parameters  I 

to  be  monitored  for  cockpit  display,  fault  Isolation  and  recording  of  long  term 
engine  health  trending  data  was  possible. 

During  Phase  III  the  list  of  parameters  was  refined  by  using  a specific 
candidate  engine  as  a baseline  for  parameter  definition.  For  the  parameter  list 
(Figures  3.2-1,  3.2-2  and  3.2-3)  preparation,  consideration  was  given  to  safe  engine 
operation  and  to  the  prediction  of  time  to  maintenance^  This  current  list  Is 
provided  to  Insure  that  a great  many  parameters  be  considered  before  final  selec- 
tion by  the  customer  with  respect  to  his  maintenance  plan/mission  mix  philosophy, 

A rational  for  the  selection  of  each  parameter  is  contained  in  Section  2,7  of  the 
Phase  III  Final  Report. 

3.2.3  Sensor  Requirements 

The  sensors  required  to  determine  the  engine  parameter  values  defined  in 

I 

Section  2.2.1  have  been  identified.  The  sensors  and  their  characteristics  are 
shown  in  the  lEIS  Sensor  Matrix,  Figure  3.2-4.  The  parameter  name,  purpose. 

Interface,  current  standard  sensor  characteristics  and  projected  sensor  character- 
istics needed  to  implement  the  lEIS  concept  are  included.  This  matrix  provides  i 

I 

a definition  of  sensor  requirements  for  lEIS.  ] 

i 

i 

i 

i 
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The  lEIS  sensor  matrix  provides  identification  of  key  functional  and 
performance  data  for  both  the  aircraft  industry  accepted  "current  standard"  and 
the  future  devices  which  will  satisfy  the  lEIS  "projected  need"  in  the  1980  to 
1985  time  period.  Only  parameters  measured  "on  engine"  are  included  in  the  matrix. 
These  are  identified  by  accepted  terminology  and  are  generally  grouped  by  the  type 
of  measurement  involved,  such  as  pressure,  temperature,  and  position.  Other  lEIS 
inputs,  such  as  air  data,  are  realistically  assumed  to  be  obtained  over  a digital 
data  bus  and  are  therefore  not  included. 

An  explanation  of  the  functional  and  performance  headings  is  provided 
in  the  following  paragraphs: 

• Type:  This  column  identifies  the  basic  sensing  technique 

employed. 

• Range:  Specific  data  provided  covers  the  F404  engine 

operating  envelope  but  should  be  fairly  repre- 
sentative of  future  variable  cycle  engines  of 
equivalent  size. 

• Output  Signal:  The  basic  signal  format  is  identified.  In  most 

cases,  some  linearity  refinements  will  be  required. 

• Accuracy:  This  parameter  defines  the  required  long  term 

performance  (1  to  2 years)  in  the  service  environ- 
ment. 

• Repeatability:  Repeatability  is  defined  as  the  allowable  short 

term  variation  in  readings  including  hysteresis, 
noise  and  resolution  factors. 

• Frequency  The  value  provided  represents  the  -3DB  band  width 

Response: 

for  the  sensing  system.  For  pressure  parameters, 
as  an  example  the  effects  of  probes,  lines  and 
cavaties  are  included. 
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• Temperature:  Expected  temperature  extremes  in  the  area  of 

the  sensing  element  are  identified,  based  on  an  a 
assumed  sensor  location  on  the  engine. 

• Vibration:  Vibration  levels  typical  of  those  used  for 

component  bench  qualification  are  provided. 

Normal  frequency  range  would  be  20  to  2000  Hz, 
but  each  engine  application  may  have  discrete 
resonances  at  higher  acceleration  levels  and 
potentially  higher  frequency  ranges. 


I 

I 

I 

I 

i 

I 

I 
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3.3 


Data  Management  Unit  (DMU) 

Functional  Description 

A functional  block  diagram  of  the  Data  Management  Unit  (IM7)  is  shown 


3.3.1 


in  Figure  3.3-1.  This  unit  is  primarily  described  in  the  Phase  III  report  and  the 
name  has  been  changed  from  Analog  Conversion  Unit  (ACU)  to  IWU  to  be  more  descrip- 
tive of  its  multiple  functions.  The  sensor  input  signals  are  specified  in  Figure 
3.2-2  and  the  output  parameters  are  specified  in  the  Sensor  Matrix,  Figure  3.2-4. 

There  are  a total  of  40  output  words  of  which  37  are  engine  parameters  and  three 
are  spares  (or  BITE  outputs).  Signal  preprocessing  is  accomplished  by  the  ac  and 
dc  signal  conditioning  circuits  and  the  vibration  and  temperature  processing  circuits. 
The  signals  are  converted  to  a 0 to  + 5 volt  level  and  applied  to  an  analog  multi- 
plexer. A 40-channel  analog  multiplexer  will  provide  for  spares  and  BITE  inputs. 

Four  samples  per  second  of  each  channel  has  been  deemed  sufficient  for  condition 
monitoring  purposes.  Therefore,  the  minimum  channel  conversion  rate  is  160  con- 
versions per  second.  A conversion  accuracy  of  0.1%  from  multiplexer  input  to 
digital  output  will  satisfy  lEIS  needs  and  presents  no  technological  challenge. 

For  ease  of  computer  interface,  the  CMU  will  contain  a small  buffer  memory  of  40 
words,  thereby  allowing  block  data  transfers  every  250  ms.  The  DMU  will  be  mounted 
near  or  on  the  engine  and  will  communicate  with  the  lEIS  data  processor  over  the 
Data  Bus.  Low  pass  filters  in  the  signal  conditioning  circuits  will  limit  the 
signal  bandwidth  at  the  input  of  the  multiplexer  to  two  Hz. 

A summary  of  the  DMU  characteristics  is  given  in  Figure  3.3-2.  The 
device  has  adequate  capacity  to  allow  for  expansion  in  the  number  of  input  channels, 
which  would  require  a corresponding  increase  in  buffer  memory.  The  multiplexer 
settling  time  has  been  included  in  the  calculation  of  channel  capacity  although 
Che  mulcipler  could  be  switching  to  a new  channel  during  the  ADC  conversion  time. 

The  sample  and  hold  module  would  Chen  be  in  the  hold  mode,  and  Che  multiplexer 
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VIBRATION 
MONITORING  UNIT 


TEMPERATURE 
MONITORING  UNIT 


ENGINE  L 

PARAMETER  J 
SENSORS  ) — [ 


AC 

SIGNAL  COND. 


r DC 

- SIGNAL  COND. 


SAMPLE 

, ANALOG/DIGITAL 

HOLD 

CONVERTER 

ADDRESS 

GENERATOR 


TIMING  AND 
CONTROL 


BUFFER 
40W  X 12B 


BUS 

INTERFACE 


FIGURE  3.3-1  DATA  MANAGEMENT  UNIT 


NO  OF  INPUT  SIGNALS 


40 
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I 

I 

I 

I 

I 
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I 
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ADC  CONVERSION  SPEED 

SAMPLE-HOLD  ACQUISITION  AND  SETTLING  TIME 

MULTIPLEXER  SETTLING  TIME 

CHANNEL  CONVERSION  TIME 

MAXIMUM  CHANNEL  CAPACITY 

SAMPLE-HOLD  APERTURE  TIME 

ADC  RESOLUTION 

BUFFER  MEMORY  SIZE 

CHANNEL  ACCURACY 


200  ps 
5.5  ;js 
10  >js 
216  yus 

4.6k  conversions/sec 
40  ns 
12  bits 
40W  X 12B 
0.10% 


FIGURE  3.3-2  DMU  CHARACTERISTICS 
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settling  time  would  be  transparent  in  channel  operation.  The  memory  buffer 
write  cycle  could  be  as  long  as  the  channel  conversion  time,  with  no  loss  of 
converted  samples.  That  is,  the  buffer  could  be  writing  the  last  sample  while 
the  ADC  processes  another.  The  read  cycle  time  will  be  dictated  by  the  l/O  bus 
transfer  rate.  For  example,  if  the  serial  bus  transfers  data  at  a one  MBPS 
rate,  the  read  cycle  must  be  less  than  12  jis. 

The  buffer  memory  will  facilitate  information  transfer  to  the  computer. 
The  intended  mode  of  operation  of  the  DMU  will  be  sequential  conversion  of  all  input 
channels,  followed  by  transmission  to  the  computer.  All  input  channels  can  be 
sampled  and  converted  in  8.64  ms  with  the  DMU  characteristics  assumed.  This 
scheme  will  allow  241  milliseconds  for  data  transmission,  a process  which  should 
take  no  more  than  one  millisecond  at  slow  (100  kbps)  bus  speeds.  Thus,  the  channel 
conversion  speed  could  be  reduced  to  six  milliseconds  while  still  maintaining  an 
adequate  data  transmission  margin.  The  buffer  memory  will  allow  the  analog  conver- 
sions to  proceed  at  a leisurely  pace  while  allowing  a reasonable  transmission  speed. 

The  DMU  can  be  configured  with  start  and  stop  registers  to  facilitate 
data  transmission  and  retry.  That  is,  the  block  transfer  command  from  the  computer 
could  contain  a start  and  stop  address  so  ;:hat  only  a portion  of  the  buffer  is 
transmitted.  This  capability  would  facilitate  retry  when  only  several  words  are 
questionable  and  the  entire  block  is  not  needed.  Alternatively,  the  buffer  could 
be  divided  into  halves  or  quarters  so  that  the  retry  command  would  point  to  a 
specific  set  of  words. 

The  Vibration  Monitoring  Unit  analyzes  the  signals  from  accelerometers 
mounted  near  the  engine  bearings,  and  its  operation  is  discussed  more  fully  below. 

The  Temperature  Monitoring  Unit  processes  the  optical  pyrometer  output  for  additional 
information  and  is  also  discussed  below.  The  ac  and  dc  signal  conditioning  circuits 
provide  the  necessary  analog  buffering,  scaling  and  ac  to  dc  conversion.  The  low 


3-19 


I 

I 

I 

I 

I 

I 

i 

I 

I 

I 

f 

I 

« 

1 


pass  filters  with  2 Hz  bandwidth  are  also  placed  here.  These  signal  conditioning 
circuits  provide  a comnon  output  voltage  range  to  the  40-  channel  analog  multi- 
plexer. The  Built-In  Test  Equipment  provides  the  self-test  functions  for  the  I%fU. 

One  common  technique  is  to  provide  a stable  test  voltage  of  known  value  at  the 
input  to  the  multiplexer.  The  bus  interface  provides  the  necessary  serial/parallel 
conversions,  transmitter/receiver  circuits,  etc.,  for  proper  data  transmission 
between  the  DMU  and  the  lEIS  data  processor.  The  details  of  the  DMU  design  can 
be  found  in  Section  3. 1.3.2  of  Che  Phase  III  Final  Report. 

3.3.2  Preprocessing 

In  the  ideal  case,  sensor  signals  would  be  digital  or  normalized  analog 
signals  and  all  of  the  processing  necessary  to  derive  the  engine  parameters  would 
be  accomplished  in  the  lEIS  data  processor.  This  approach  is  the  most  efficient 
but  because  of  economic  and  technical  limitations  in  the  proposed  time  frame  certain 
sensor  preprocessing  is  required.  The  ac  and  dc  signals  (Figure  3.2-4)  must  be 
detected,  filtered  (2  Hz),  normalized  to  be  compatible  with  the  multiplexer  input. 

The  turbine  blade  temperature  and  accelerometer  signals  require  more  extensive 
preprocessing  which  is  described  in  detail  below. 

Evaluation  of  the  computer  capacity  required  to  perform  these  two  functions 
digitally  was  conducted  in  Phase  IV  and  it  was  concluded  that  it  was  not  feasible. 

(See  Sections  2.4.1  and  2.4.2  of  the  Phase  IV  Final  Report.) 

3.3.2. 1 Vibration  Monitoring 

The  VM  circuit  receives  those  signals  and  provides  those  outputs  listed 
in  Table  3.3-1.  The  VM  circuit  monitors  the  engine  mounted  accelerometer  outputs 
and  provides  the  analog  processing  to  Indicate  FOD  and  bearing  condition  mass  un- 
balance. The  VMU  employs  multiplexing  techniques  whenever  possible  and  requires 
interface  with  the  fan  and  core  speed  sensors. 


! 
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TABLE  3.3-1  - 

VMU  INPUTS  AND 

OUTPUTS 

Parameter 

Name 

Range 

Units 

Inputs 

Vibration  1 

Vib  1 

0+500 

G's 

Vibration  2 

Vib  2 

0+500 

G's 

Outputs 

FOD  Flag  1 

FODF  1 

On/Off 

— 

FOD  Flag  2 

FODF  2 

On/Off 

— 

Bearing  Condition  1 

Brg  1 

0+10 

— 

Bearing  Condition  2 

Brg  2 

0+10 

— 

Mass  Unbalance  1 

MUM  1 

0+10 

MILS 

Mass  Unbalance  2 

MUM  2 

0+10 

MILS 

The  high  output  impedance  charge  signals  proportional  to  acceleration 
from  the  two  engine  mounted  accelerometers  are  accepted  by  the  VMU  and  converted 
to  low  impedance  voltage  signals  by  independent  charge  converters  and  voltage 
amplifiers.  These  amplifiers  provide  the  initial  buffering  for  subsequent  multi- 
plexing and  further  processing.  A block  diagram  of  the  VMU  is  shown  in  Figure  3.3-3. 

The  Foreign  Object  Damage  analysis  section  of  the  VMU  provides  continuous 
monitoring  of  each  input  vibration  channel.  This  function  cannot  be  time  multiplexed 
due  to  the  random  nature  of  the  phenomenon.  The  input  signals  are  peak  detected  and 
then  compared  to  a threshold  to  determine  the  presence  or  absence  of  FOD.  The  peak 
detector  is  automatically  reset  after  an  appropriate  interval  by  the  FOD  flag  to 
allow  further  FOD  Indications.  This  Interval  is  determined  by  the  downstream  digital 
sampling  rate.  A minimum  250  ms  delay  is  required  by  the  present  DMU-IEIS  design. 
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The  bearing  condition  is  determined  using  multiplexing  techniques 


The  analog  processing  computes  the  acceleration  signal  Ioq>act  Index,  a normalized 
dimensionless  quantity.  The  value  of  this  index  is  indicative  of  bearing  condition. 

The  Impact  Index  is  a ratio  of  the  peak  value  to  the  RMS  value  of  the  complex  vibra- 
tion signal.  Normally,  this  Index  is  less  than  three. 

The  VMU  contains  multiplexed  unbalance  monitors  for  measuring  the  narrow- 
band fan  and  core  displacement.  This  displacement  is  determined  by  double  integrating 
the  multiplexed  acceleration  signals  and  filtering  at  the  once/rev.  frequency  using 
narrowband  tracking  filters.  These  filters  are  tuned  using  synchronizing  signals 
derived  from  the  fan  and  core  speed  sensors.  Only  the  vibration  energy  associated 
with  the  relevant  fan  and  core  speed  is  allowed  to  pass. 

3.3.3  Analog  To  Digital  Conversion  (ADC) 

Several  different  configurations  of  ADC  were  investigated  and  tradeoffs 
made  to  determine  which  is  the  most  cost  effective  approach.  The  multiplexer, 
sample  and  hold  and  slow  speed  A/D  converter  configuration  was  selected.  This 

1 

circuitry  is  shown  in  the  ro(U  functional  block  diagram.  Figure  3.3-1.  | 

1 

The  basic  engine  time  constant  --  several  seconds  from  idle  to  take-off  | 

RFM  — governs  most  of  the  changes  in  parameters  which  lElS  monitors.  In  addition,  j 

trending  and  condition  monitoring  will  only  be  performed  at  stable  flight  conditions.  ^ 

The  sampling  of  each  parameter  is  done  at  four  samples/second.  With  40  input  signals, 
the  required  capacity  of  the  DMU  is  160  conversions /second  which  requires  a conver- 
sion time  of  6.25  ms.  This  channel  conversion  period  is  made  up  of  multiplexer 
settling  times,  as  well  as  the  analog  to  digital  conversion  time.  The  conversion 
period  for  the  proposed  mu  is  216  micro-seconds  and  typical  A/D  converter  and 
san9>le  and  hold  specifications  are  shown  in  Figures  3.3-4  and  3.3-5  respectively. 

To  meet  this  requirement  the  multiplexer  delay  must  be  10  yC(_sec,  which  is  readily  ^ 

attainable.  This  circuitry  will  provide  the  0.17.  parameter  accuracy  requirement 
Including  both  static  and  dynamic  errors.  The  static  error  is  estimated  to  be 


iJ 
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Quantization  Error 

+ h lsb 

Resolution 

12  BITS 

Linearity  (@  25°C) 

+ k.  LSB 

Gain  Drift  (0-70°C) 

+ 7 ppm/C° 

Offset  Drift  (0-70°C) 

+ 2 ppm/C° 

Linearity  Drift  (0-70°C) 

+ 3 ppm/C° 

Input  Impedance 

10®-O. 

Dynamic  Signal  Range 

10  V 

Conversion  Speed 

200  yCAS 

FIGURE  3.3-4  - TYPICAL  12-BIT  ADC  PERFORMANCE  SPECIFICATION 


DYNAMIC  RANGE 
INPUT  IMPEDANCE 
BIAS  CURRENT 
GAIN  DRIFT 
OFFSET  DRIFT 

DROOP  RATE 
DROOP  RATE  DRIFT 
APERTURE  TIME 
ACQUISITION  TIME 

10  V STEPS  TO  0.005^ 
20  V STEPS  TO  0.005^ 
DYNAMIC  NON-LINEARITY  @ 
1000  us  HOLD  TIME 
SETTLING  TIME  TO  1 MV 


+ 10  VOLTS 
10®  OHMS 
30  NA 

+ 20  pw/oc 
+ 25  jav/°C 
20  /iv/MSEC  (MAX) 
DOUBLES  EVERY  10°C 
40  NS 

4 >U5 

5 /Js 

+ 0.005%  of  20  V 
500  ns 


FIGURE  3.3-5  TYPICAL  SAMPLE-HOLD  SPECIFICATIONS 
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0.0597.  which  allows  0.0417.  for  dynamic  errors.  The  typical  sample  and  hold  circuit 
and  A/D  converter,  and  an  analog  multiplexer  and  signal  conditioning  amplifer, 
with  combined  output  impedance  of  1000  ohms  were  considered  in  arriving  at  the 
static  error. 

3,3.4  Data  Bus 

3.3.4. 1 lEIS  Data  Transmission  Requirements 

Preliminary  estimates  of  data  rate  requirements  are  given  in  Table  3.3-2. 
An  18-  bit  interface  is  indicated,  although  it  may  actually  vary  from  subsystem  to 
subsystem.  The  main  conclusion  to  be  drawn  from  this  list  is  the  very  low  trans- 
mission requirements  placed  on  the  lEIS  processor  interface. 

The  18  kbps  total  data  is  a preliminary  estimate  and  represents  an 
average  requirement.  Display  formats  will  be  pointed  to  as  subroutines  by  the  lEIS 
processor.  The  display  generator  will  contain  its  own  Format  and  Parameter  Tables 
and  will  provide  the  display  refresh  function.  The  Data  Recorder  will  operate  in 
a burst  mode,  recording  approximately  70  parameter  averages  over  a five-minute 
interval.  The  data  recorder  will  not  operate  continuously  but  will  record  data 
on  exception  and  at  specified  flight  conditions.  Similarly,  inputs  from  A/C  systems 
are  not  required  continuously.  Allowing  a 1007.  margin  in  the  total  estimate  still 
represents  a relatively  simple  1/0  traffic  problem. 

3. 3. 4. 2 lEIS  Data  Bus  Architecture 

lEIS  Data  Transmission  requirements  are  quite  small  in  relation  to  the 
overall  requirements  of  the  information  transfer  system  for  the  lEIS  aircraft.  lEIS 
is  not  self-sufficient  in  the  sense  that  it  must  relay  on  other  systems  for  data 
inputs  and  outputs.  Thus,  although  there  will  be  a "local"  lElS  data  bus,  the 
system  must  eventually  interface  with  "other"  A/C  data  buses.  The  existence  of 
"other"  buses  implies  system  integration  at  a level  higher  than  lElS,  and  the 
standardization  of  data  bus  interface  for  all  A/C  systems. 
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1 SUBSYSTEM 

NO.  OF 
WORDS 

BITS/ 

WORD 

AVERAGE 
SAMPLE 
RATE  (m.) 

TOTAL 
BITS  CBPS) 

1 

DATA  MANAGEMENT  UNIT  1 

18 

4 

2880 

1 DATA  MANAGEMENT  UNIT  2 

40 

18 

4 

2880 

ELECTRONIC  ENGINE  CONTROL 

1 

1 

20 

18 

4 

1440 

» ELECTRONIC  ENGINE  CONTROL 

2 

20 

18 

4 

1440 

. A/C  INTERFACE 

211 

18 

4 

1512 

' KEYBOARD 

1 

18 

4 

72  . 

1 lEIS  DISPLAY 

100 

18 

4 

7200 

1 

DATA  RECORDER 

130 

18 

.5 

1170  I 

j MAINTENANCE  DISPLAY 

1 

18 

.1 

2 1 

18596  1 

I 

I 

I 

1 

I 

I 
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lEIS  consists  of  the  Computer,  Display  and  Keyboard,  Data  Management 
Units,  Maintenance  Status  Indicator  and  Data  Recorder.  The  other  A/C  systems  of 
Figure  2.1-1  are  on  "other"  buses.  The  lEIS  Data  Bus  architecture  would  probably 
conform  to  the  MIL-E-XXX  Data  Bus  (similar  to  MIL-STD-1553)  specification  command 
response  configuration  (see  Figure  3.3-6).  This  bus  architecture  will  more  than 
adequately  meet  the  data  transmission  requirements  and  a block  diagram  is  shown 
in  Figure  3.3-6.  Bus  control  would  reside  in  the  lEIS  processor  with  remote 
terminals  in  lEIS  subsystem  units.  The  computer  would  communicate  with  each  unit 
and  other  aircraft  systems.  The  modulation  scheme  will  be  the  Manchester  code 
which  has  self-clocking  ability  and  easy  bus  interface.  The  transmission  media 
will  be  shielded  twisted  pair,  unless  the  problems  of  fiber  optics  are  overcome 
and  its  capabilities  are  demonstrated.  The  bus  would  operate  in  a bit  serial, 
word  serial  fashion.  The  time  division  multiplexed  system  would  operate  at  base- 
band with  a one  MBPS  bit  rate.  This  is  more  than  adequate  for  lElS  needs. 

3.4  Data  Processing 

3.4.1  lEIS  Software  Definition 

3. 4. 1.1  Software  Requirements 

Preliminary  functional  requirements  of  Engine  Monitoring  Computer 
Program  (EMP)  were  established  during  Phase  III  in  sufficient  detail  to  provide 
a basis  for  estimating  the  data  processor  memory  capacity  processor  utilization 
(based  on  IMOPS  machine)  necessary  to  implement  the  lEIS  system.  During  Phase 
IV  these  requirements  were  reviewed  and  estimates  of  memory  capacity  and  processor 
utilization  were  revised  based  on  projected  improved  efficiency  of  the  program  and 
use  of  the  All  Applications  Digital  Computer  (AADC). 

The  major  functions  of  the  EMP  Program  are  to  sample  appropriate  input 
signals  at  an  adequate  rate  to  determine  unambiguously  the  present  engine  use  con- 
dition among  the  following  possible  modes: 

• Pre -Start 

• Start 

• In-Use 

• Shutdown 
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For  each  mode,  the  program  must  perform,  at  appropriate  rates,  all  the  actions 
needed  to  maintain  a routinely  required  display,  compare  measured  engine 
operating  parameters  against  model-predicted  values  , record  parameters  useful 
for  long-term  engine  performance  prediction  (by  ground  analysis)  , perform  short- 
term engine  performance  trend  analysis,  generate  special  displays  if  engine 
abnormalities  are  evident  either  immediately  or  from  short-term  trend  analysis , 
maintain  engine  performance  records  , respond  to  crew  initiated  requests  for  display 
of  selected  data  and  results  concerning  engine  performance  or  energy  management 
predictions  , perform  readiness  and  self-test  checks  on  the  hardware  elements  of 
the  lEI  System  (including  the  computer  itself)  and  to  initiate  appropriate  correc- 
tive actions  whenever  faulty  operation  is  detected. 

3.4. 1.2  Sumnarv  of  Software  Elements 

A preliminary  definition  of  the  software  elements  needed  to  satisfy 
the  requirement  defined  above  was  accomplished  during  Phase  III.  The  operational 
lEIS  software  elements  are  Identified  in  this  section  by  English  language  flow 
charts  and  flow  chart  descriptions  for  each  phase  of  engine  operation.  A 
more  detailed  definition  of  the  software  elements  is  contained  in  Section  4.3.7  of 
the  Final  Report  Phase  III. 

3.4. 1.2.1  Pre-Start  Operational  Software 

The  lEIS  pre-start  operational  software  is  flow  charted  in  Figure  3.4-1. 
Entry  to  this  segment  of  the  operational  program  results  from  the  power-on  start 
of  the  computer  system.  Self-test  of  the  lEIS  is  accomplished  first. 

System  reconfiguration  to  by-pass  detected  faults  is  accomplished,  if  needed,  by 
sharing  non-IEIS  resources  as  follows: 

e Within  the  AADC  System  for  processor/recorder  or  memory  faults 
e Within  the  AIDS  for  display  faults 

e Within  the  Data  Bus  System  for  data  transmission  faults 
e By  modification  of  the  linkage  table  for  the  engine  model  sub- 
routines for  sensor  faults 
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FIGURE  3.4-1  PRE-START  FLOW  DIAGRAM 
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FIGURE  3.4-1  PRE-START  FLOW  DIAGRAM  (Cont'd) 


Once  Che  lEIS  is  found  to  be  operational,  initialization  of  data 
Cables  for  Che  following  is  accomplished: 

• Short-term  trending  records 

• Loop  record 

• Pre-flight  fuel  consumption  schedule 

A check  for  uncleared  MSI  flags  is  made  and  a warning  is  displayed  if 
any  flags  are  found.  The  operating  system  for  scheduling  the  iterative  tasks 
during  pre-start  is  then  loaded  and  control  transferred  to  it. 

Iterative  tasks  are  limited  to  the  following: 

• Reading  current  values  of  all  engine  sensors  and  posting  these 
as  the  first  (and  only)  entry  in  the  loop  record. 

• Scanning  the  entire  pre-start  engine  check-list  and  displaying 
all  unsatisfied  entries. 

• Responding  to  pilot  keyset  requests  for  display  sensor  data. 

Each  iterative  cask  is  followed  by  a step  to  test  the  signal  indicating 
application  of  starter  power. 

Once  the  application  of  starter  power  is  sensed,  the  current  loop  record 
data  set  is  transferred  to  the  recorder  as  the  first  (pre-start)  performance  record. 

The  pre-start  display  is  replaced  with  the  identifiers  for  the  parameters  displayed 
during  engine  start  and  control  is  transferred  to  the  engine  start  routine. 

3. 4. 1.2. 2 Engine  Start  Software 

The  flow-chart  of  the  software  executed  during  engine  start  is  shown 
on  Figure  3.4-2. 

The  process  is  a single  iterative  task  composed  of  data  collection 
from  all  engine  sensors  and  cumulative  time  of  attempted  start.  This  data  is  preserved 
as  a loop  record.  In  addition  the  current  values  of  the  following  are  displayed: 

e Core  RPM 

• Fan  RPM 
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FIGURE  3.4-2  ENGINE-START  FLOW  CHART 


• Turbine  Blade  Temperature 

• Ignition  Input 

• Lube  and  Fuel  Flow 

• Elapsed  Start  Time 

Further  out-of-limits  checks  are  made  on  the  following  parameters; 

• Fuel-Flow 

• Ignition  Input 

• Lube  Pressures 

• Lube  Flows 

• Elapsed  Start  Time 

If  any  parameters  are  out-of-limit,  a warning  display  is  produced  and  the  loop  record 
dump  is  commenced.  The  condition  for  successful  start  (core  speed  exceeds  a threshold 
value)  is  monitored  as  well  as  the  continuation  of  starter  power.  If  starter  power 
is  removed  without  a start  having  been  achieved  or  if  abnormal  temperatures  are 
reached  at  start,  the  loop  data  record  is  made  available  for  external  analysis  and 
the  corresponding  MSI  flags  are  set.  Control  is  returned  to  the  pre-start  program. 

If  a normal  start  is  achieved,  a performance  record  is  transferred  to  the  recorder. 
This  record  is  augmented  by  the  time-to-start  datum  and  is  identified  by  a unique 
header.  Program  control  in  this  case  is  transferred  to  the  Engine- in-Service  Program. 
3. 4. 1.2. 3 Engine-In-Servlce  Software 

A flow  chart  representation  of  the  computational  tasks  performed  while 
an  engine  is  in  service  is  shown  as  Figure  3.4-3. 

The  principal  routines  are  the  following: 

• Sensor  data  processing  scheduled  every  second 

• Fuel  status  check  Irregularly  scheduled  on  basis  of  elapsed 

flight  time  only 

• Performance  record  Scheduled  approximately  each  1/20  of 

planned  flight  duration  plus  interrupt  on 
take-off 
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• Sample  keyset  Interrupt,  generated  unpredictably 

requests 

• System  Self-Test  Background-run  only  if  no  other  purpose 

is  required 

Sensor  Data  Processing 

Sensor  data  processing  comnences  once  each  two  seconds  when  the  data 
acquisition  equipment  has  obtained  four  samples  from  each  of  the  engine  sensors 
and  has  stored  these  in  digital  form.  The  first  operation  is  to  convert  the 
stored  number  to  the  value  representing  the  original  physical  variable  measured 
in  the  appropriate  units.  This  operation  generally  involves  correction  of  bias 
errors  and  multiplication  by  a scale  factor.  More  elaborate  calibration  curve 
corrections  are  needed  in  some  instances.  The  mean  and  deviation  of  the  four 
measurements  are  then  computed  for  each  sensor.  Checks  for  hard  failure  of  a 
sensor  and  the  computation  of  the  deviation  in  the  samples  constitute  a continuous 
operation  monitoring  of  the  sensor.  The  mean  of  the  four  samples  is  stored  in  the 
computer  memory  as  the  entry  in  the  loop  record  for  the  measurement  for  the  current 
one-second  interval. 

The  fuel  quantity  and  fuel  flow  rate  measurements  are  combined  in 
accord  with  a suitable  smoothing  procedure  to  form  the  best  estimate  of  fuel 
remaining. 

The  current  rate-of-change  of  the  engine  model  "trigger"  input  vari- 
ables (over  the  three-minute  period  spanned  by  the  loop  record)  are  computed  and 
stored  for  later  use  if  needed  in  selecting  the  best  data  set  for  permanent  record- 
ing as  part  of  the  engine  performance  and  long-term  trending  record. 

Those  measurements  that  can  be  compared  against  fixed  limits  are  then 
checked  for  limit  exceedance.  Foreign  object  damage  flags,  air  bleed  rates,  mass 
unbalance  measurements  fall  in  this  category. 

If  a limit  has  been  exceeded,  then  the  corresponding  changes  to  the 
maintenance  status  display  and  the  pilot's  display  are  made. 
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Next,  the  conditions  for  stable  engine  operation  are  checked.  Stable 

engine  operation  requires  that  the  rate  of  change  of  the  following  "trigger"  para- 
meter are  near  zero; 

• Fan  Speed 

• Inlet  Total  Temperature 

• Inlet  Total  Pressure 


Also,  fan  speed  must  be  above  idle.  If  operating  conditions  are  stable,  the 
programmed  engine  model  is  run  whenever  a significant  change  in  its  trigger  (input) 
variables  has  occurred.  The  outputs  of  this  programmed  model  are  the  numerical 
values  of  sensor  parameters  (and  quantities  directly  derivable  from  them)  that  an 
average  engine  would  have  had  when  new  and  operated  under  identical  input  conditions. 

The  relative  errors  between  sensor  readings  (or  data  derived  from  sensor 
readings)  and  the  corresponding  output  of  the  engine  model  are  then  computed.  If 
these  relative  errors  exceed  their  respective  assigned  limits,  the  corresponding 
display  changes  and  advisories  are  made  and  the  MSI  record  posted. 

In  the  event  that  the  engine  ingests  rain,  sleet  or  snow,  a number  of 
gas-path  parameters  will  simultaneously  show  out-of-limit  behavior.  The  character- 
istic pattern  of  these  apparent  failures  is  recognizable.  Hence,  the  occurence  of 
any  one  of  them  will  not  result  in  display  changes  and  loop  record  dump  until  a 
programmed  check  is  made. 

The  final  operation  is  to  update  the  extrapolation  of  those  parameters 
that  are  subject  to  short-term  trending.  If  the  extrapolated  value  (three  minutes 
ahead)  lies  outside  of  acceptable  limits,  a cautionary  display  of  a predicted  out- 
of-limit  condition  is  made.  Short-term  trended  variables  Include  the  mass-unbalance 
and  vibration  signals. 
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Status  Check 


The  flight  plan  check-points  for  fuel  expenditure  trigger  the  programmed 
fuel  status  check.  The  comparison  between  predicted  and  actual  fuel  consumption  is 
made  and  the  result  displayed  for  a sufficient  interval  to  insure  pilot  attention 

Performance  Record 

Each  entry  in  the  performance  recor^^j-ef^iT  engine  consists  of  a full  set 
of  averaged  sensor  readings  and  ^_rje€J»#9^^1eader  identifying  the  time,  position,  and 
flight  conditiotw^At-TtflTich  th«^'r^ord  was  made. 

One  such^'^try  is  made  for  each  engine  on  each  flight  using  the  data 
set  containijjg^he  highest  value  of  turbine  blade  temperature  from  among  those 
obs%rv^  during  the  three  minutes  preceding  and  the  one  minute  following  the  sensing 
of  take-off.  Take-off  is  sensed  by  load  relief  on  the  landing  gear  or  support  struc- 
ture, in  the  VTOL  case. 

An  additional  entry  is  made  whenever  the  one-minute  least-squares 
estimate  of  the  rate  of  change  of  the  stability  criteria  first  reaches  a sufficiently 
small  value.  Each  two  minutes  thereafter,  so  long  as  the  stability  criteria  remains 
satisfied,  another  entry  is  made. 

At  the  end  of  each  period  equal  to  one-twentieth  of  the  planned  flight 
time,  an  examination  is  made  to  determine  the  current  number  of  flight  performance 
records  stored.  If  fewer  than  N+2  entries  have  been  made,  where  N is  the  number  of 
periods,  a new  data  set  from  among  the  90  sets  stored  as  the  loop  record  is  entered. 
Selection  of  the  set  to  be  entered  is  determined  by  checking  stability  parameters. 

The  set  with  the  smallest  deviations  from  stability  is  chosen. 

System  Self-Test 

When  scheduling  conditions  are  such  that  no  predictable  task  will  be 
required  within  the  run-time-interval  of  the  lEIS  self-test,  the  self-test  program 
is  run. 
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The  program  tests  the  Data  Management  Unit  and  its  communication 


pathway,  processor  arithmetic  and  logic  nnara-r ions . .processor  memory  (sampled), 
-recSfUer  electronics  and  status,  and  outputs  from  some  regions  of  the  display 
surface.  , 


3, 4. 1.2, 4 Engine  Shutdown  Software 

A flow-diagram  of  the  software  procedure  following  detection  of  engine 
shutdown  is  shown  as  Figure  3.4-4. 

If  the  shutdown  occurs  while  air-borne,  a display  of  the  data  required 
to  judge  the  feasibility  and  safety  of  air-restart  is  presented.  Then  parameters 
indicative  of  successful  re-start  are  monitored  and  if  restart  occurs,  program 
control  is  returned  to  the  engine- in-service  procedure.  If  the  restart  is  unsuc- 
cessful, normal  engine  shutdown  procedures  are  performed  when  the  aircraft  is  landed. 
Engine  component  service  time  records  are  updated  as  a part  of  the  normal  shutdown. 
Program  control  is  then  transferred  to  the  pre-start  routine. 

3.4.2  lEIS  Computer 

3.4.2. 1 lEIS  Computer  Requirements 

Based  on  the  software  definition,  initial  estimates  of  the  computer 
requirements  to  implement  the  lEIS  operational  system  were  made  during  Phase  III. 

The  processing  time  to  accomplish  the  software  tasks  were  estimated  on  the  basis 
that  certain  hardware  features  were  available. 

The  software  performance  numbers  are  based  on  the  following  assumptions: 
the  basic  CPU  performs  dyadic  operations  at  the  same  rate  as  monadic  functions  (i.e. 
the  processor  has  more  than  one  data  transfer  path  to  the  arithmetic  unit);  shift 
operations  are  "one-pass"  regardless  of  length;  floating  point  hardware  permits 
maximum  parallelism  in  execution  of  floating  point  add/subtract/multiply/divide; 
fixed-point  multiply  and  divide  are  performed  at  least  two-bits  per  microstep; 
exponential/log  operations  are  hardware  aided  such  that  one  bit  of  result  is 
produced  for  each  two  microsteps;  bit  and  byte  addressing  of  memory  and  registers 
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provided;  concurrent  I/O  control  operations  are  performed  with  single  word  memory 
access  for  each  word  transferred  (i.e,  the  1/0  processor  has  sufficient  local 
storage  for  its  bookkeeping  operations);  interrupt  processing  and  priority  level 
detection  is  hardware  aided  to  the  extent  that  transfer  from  the  interrupt  routine 
to  a higher  priority  interrupt  routine  or  return  to  main  line  is  accon5>lished  in 
a single  average  instruction  execution  time  and  hardware  means  exist  to  generate 
"chronic"  interrupts.  The  effects  on  software  execution  time  of  not  having  these 
computer  hardware  fixtures  will  have  to  be  assessed  when  the  hardware  fixtures  are 
Identified. 

The  memory  requirements  were  estimated  in  terms  of  program  storage 
and  working  storage.  This  approach  was  taken  to  better  define  the  type  as  well  as 
the  amount  of  memory  required.  Program  storage  will  require  non-volatile  type 
memory  so  that  programs  are  retained  permanently.  Types  of  non-volatile  memories 
to  be  considered  for  application  in  lEIS  include  the  following: 


• MNOS 

• Plated  Wire 

• Core 

• Closed  Flux  Memory 

• Semiconductor  ROM  j 

Memory  access  times  should  be  consistent  with  the  processor  speed  requirement  and  j 

I 

the  memory  hierarchy  employed  in  the  computer.  The  processor  accuracy  requirements 
can  be  met  by  a 32  bit  word. 

i 

A sunmary  of  the  processing  time  and  memory  requirements  is  shown  in 
Figure  3.4-5.  There  are  two  estimates.  One  is  based  on  a dedicated  IMPOS  computer 
and  assumes  a constant  memory  access  time  for  program  and  working  storage.  The 
other  estimate  is  based  on  the  2 MOPS  AADC  configuration.  The  non-volitale  Bulk 
Oriented  Random  Access  Memory  (BORAM)  for  the  AADC  is  page  oriented  with  256  words /page 
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and  page  transfer  times  are  significant  for  short  programs.  This  characteristic 

partially  accounts  for  the  ratio  of  processing  times  not  being  equal  to  the  ratio 
of  operating  speeds  (2:1).  Other  differences  should  be  also  noted.  The  Self  Test 
feature  is  more  extensive  for  the  1 MOPS  machine  because  the  complete  system  is 
tested.  The  AADC  estimates  assume  that  the  self-test  is  accomplished  by  a higher 
level  system  computer. 

3. 4. 2. 2 Computer  Characteristics 

Rapid  Interrupt  Response 

The  lEIS  software  is  directed  to  perform  the  most  urgent  task  ready  at 
any  instant  by  hardware  interrupts.  The  programming  burden  that  interrupt  service 
imposes  is,  in  general,  the  following: 

Preserve  the  current  state  of  the  machine  so  that  it  can  resume  the 
interrupted  routine  at  a later  time;  and  condition  the  l/O  interrupt  enables  so 
that  the  interrupting  routine  may  itself  be  interrupted  only  by  routines  of  higher 
priority  than  its  own. 

The  first  of  these  tasks  can  be  accomplished  by  non-interruptable 
hardware  or  microprogram  transfer  of  the  contents  of  all  central  registers,  the 
current  state  of  the  I/O  interrupt  register  and  its  enabling  mask  and  the  machine 
status  register  and  instruction  address  to  a set  of  reserved  memory  locations.  Such 
a solution  is  not  without  problems.  For  example,  if  the  reserved  locations  serve 
all  levels  of  interrupts,  the  interrupting  routine  must  run  interrupt  insensitive 
until  it  can  transfer  the  contents  of  the  reserved  locations  to  some  other  place 
in  memory.  Otherwise,  the  return  data  may  be  overwritten  by  a second  interrupt.  A 
somewhat  better  solution  is  to  reserve  a set  of  memory  locations  for  each  Interrupt  and 
have  the  hardware  or  a microprogram  do  the  safe  store  upon  recognition  of  an  interrupt. 
An  ideal  solution  would  be  to  have  completely  separate  sets  of  central  registers  or 
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push-down  stacks  for  every  level  of  interrupt.  Then,  when  an  interrupt  is 
recognized,  a base  register  is  changed  to  point  to  the  set  serving  the  inter- 
rupting routine  while  the  register  set  serving  the  interrupted  routine  is  simply 
abandoned  as  is,  but  ready  for  return  to  use  at  any  time. 

The  second  task,  conditioning  the  l/O  state  in  a way  suitable  for  the 
interrupting  routine,  can  be  a simple  hardware  or  microprogram  action  requiring 
one  more  reserved  memory  location.  Surprisingly,  few  machines  have  this  feature. 

A rather  awkward  and  dangerous  substitute  is  to  grant  (by  hardware)  freedom  from 
interruption  of  the  first  instruction  following  recognition  of  an  interrupt  or 
alteration  of  the  interrupt  enable  state. 

Without  efficient  hardware  aid  in  interrupt  transfers,  otherwise  high 
speed  machines  may  suffer  50-100  ^s  software  overhead  delays  in  responding  to 

interrupts  and  thus  be  seriously  impaired  in  real-time  applications  like  lEIS. 

/ 

Chronic  Interrupt  Generation 

The  lEIS  software  requires  a number  of  periodic  interrupts  of  various 
periods.  Hardware  clocks  can  be  provided  to  handle  a few  such  interrupts  by  having 
separate  registers  and  compare  logic  for  each  of  them.  When  there  is  a need  for 
several  such  interrupts , the  temptation  to  share  the  comparison  logic  becomes  quite 
high.  An  associative  memory  performing  a "less  than"  search  against  the  real-time 
clock  each  time  it  changes  state  would  be  one  possibility.  Another  would  be  to  obtain 
the  same  effect  by  completely  rotating  a hardware  shift-register  and  comparing  each 
stage  of  it  against  the  clock  whenever  the  clock  changes  its  count.  A third  alterna- 
tive which  would  not  require  special  hardware  but  which  would  be  quite  helpful  is 
to  include  a machine  language  instruction  as  follows: 

Decrement  memory  and  transfer  if  zero,  replace  on  transfer  from 
next  memory  location. 
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In  the  absence  of  such  an  instruction,  the  supervisory  program  has  to 
execute  a subroutine  which,  in  the  worst  case,  could  be  the  nine  following  instructions 


Register-to-Memory  (to  make  register  available) 
Register-from-Memory  (current  "clock"  reading) 


STORE 
LOAD 

DECREMENT  Register 
TRANSFER  ON  ZERO  to  A 

STORE  Register  (updated  to  clock  location) 

LOAD  Register-from-Memory  (to  restore  original  contents) 

A LOAD  Register  (interrupt  period) 

STORE  Register  (to  clock  location) 

LOAD  Register  (to  restore  original  contents) 

Such  an  instruction  would  also  be  useful  in  setting  up  control  of  f ixed-number-of- 
iteration  loops  in  a progr^un. 

Monadic  Operations  On  Memory 

lEIS  programs,  in  common  with  practically  all  others,  can  save  an  overhead 
pair  of  register  (safe-store  and  recover)  instructions  if  all  monadic  operations  can 
be  performed  on  any  memory  location  by  microprogram  use  of  central  registers  that 
are  not  accessible  to  the  normal  program.  A fairly  complete  set  of  monadic  operations 
are  the  following: 

• Logical  Invert 

• Arithmetic  Complement 

• Absolute  Value 

• Normalize 

• Shift  (All  Variations) 

• Increment 

• Decrement 

• Convert  Fix-to-Float 
a Convert  Float-to-Fix 

• Square 

a Square  Root 
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Single  Pass  Shifting 

In  a floating  point  machine  which  performs  shift  operations  in  a time 
proportional  to  the  length  of  the  shift,  the  time  required  to  perform  additions 
and  subtractions  becomes  indeterminate.  Hence,  the  only  way  to  establish  the 
running  times  of  arithmetic  subroutines  is  by  statistical  methods.  In  the  lEIS 
case,  as  for  most  other  real-time  systems,  the  possibility  of  having  extreme 
running  times  for  some  subroutines  leads  to  the  possibility  of  scheduling  dif- 
ficulties and  occasional  system  blow-ups.  If  the  machine  is  equipped  with  the 
hardware  needed  to  perform  shifts  in  a single  operation,  instruction  execution 
times  become  determinate  and  precisely  predictable.  Data  Independent  instruction 
execution  times  are  highly  desirable,  if  not  mandatory,  for  good  system  design 
and  single  pass  shifting  is  a sine-qua-non  to  reach  this  goal  in  a floating  point 
arithmetic  machine. 

Hardware  (Firmware)  Library  Functions 

Library  subroutines  normally  encompass  the  most  frequently  used  functions 
of  analysis.  A typical  set  includes  the  following: 


• Sin  X 


• Cos  X 

• Tan"^  X 
a Cosh  X 

• Sinh  X 

• Tanh”^  X 


• Ln  (X) 

• Jx^  + 

• pT 


The  trigonometric  functions  are  of  special  importance  to  lEIS  since  certain 
multidimensional  look-up  tables  could  be  replaced  by  multidimensional  Fourier 
series  approximations  if  high  speed  evaluations  of  the  trigonometric  functions 
were  available. 

The  functions  of  the  form  are  valuable  in  any  model  of  thermo- 
dynamic processes. 

The  generalized  multiply  operation  of  J.  MeggiCt  provides  an  algorithm 
for  evaluating  these  functions  in  a digit-by-digit  fashion  well  suited  to  special 
purpose  hardware  implementation  or  microprogramming.  Another  implementation 
possibility  is  microprogrammed  evaluation  of  Chebychev  polynomial  approximations 
for  these  functions.  Which  approach  is  better  depends  upon  machine  capabilities. 

A fast  shift  network  generally  predisposes  one  to  choose  the  Meggitt  algorithm. 

A special  problem  occurs  with  a system  required  to  produce  a numerical 
display.  The  human  user  needs  the  data  presented  to  him  in  decimal  form.  The 
machine  has  numbers  in  a base  two  floating  point  form.  Conversion  from  machine 
floating  point  to  a sequence  of  ASCII  coded  decimal  digits  is  a time-consuming 
editing  function  when  done  by  normal  software  means.  The  desirability  of  a firm- 
ware aid  in  this  chore  should  be  examined. 

Loop  Indexing 

A large  part  of  the  lEIS  Program  involves  the  performance  of  a small 
subroutine  on  each  element  of  a list  of  data.  The  machine  language  program  can 
be  significantly  reduced  by  an  index  manipulating  instruction  that  steps  the  index, 
tests  it  for  completion  and  returns  control  to  the  top  of  the  loop  if  runout  has 
not  occurred  and  proceeds  otherwise.  The  typical  machine  program  would  read  as 
follows: 

Add  to  index  from  memory  (Add  the  step  increment) 

Compare  with  memory  (Compare  loop  limit) 

Transfer  on  not  greater  to  top  of  loop 

The  entire  process  can  be  specified  by  a single  instruction  with  a field  to  designate 
the  index  register  to  be  operated  upon  and  a memory  address  field  to  point  to  the 
first  of  a three-word  sequence  which  stores  in  order  the  step  size,  the  stopping 
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value  of  the  index,  and  Che  address  for  Che  first  instruction  in  Che  range  of  the 
loop.  Microprogramning  of  the  process  saves  two  instruction  fetches  and  gives  at 
least  a three-to-one  inq>rovenienc  in  program  compactness.  A variation  of  this 
instruction  for  a step  size  of  unity  (the  most  frequent  case)  would  require  only 
two  memory  locations. 

Subroutine  Linkage  Instructions 

f 

The  lEIS  Programs,  as  is  true  for  most  large  programs,  must  be  written 
with  free  standing,  re-entrant,  pure  procedure  subroutines  which  can  be  called 
by  a variety  of  using  programs  or  linked  in  different  sequences  as  required.  When 
a subroutine  can  be  called  by  a multiplicity  of  using  programs,  the  following 
technical  problems  must  be  solved: 

• A mechanism  must  be  provided  so  that  once  the  called  subroutine 
is  executed,  control  can  be  returned  to  the  correct  using  routine. 

• A mechanism  must  be  provided  for  the  using  routine  to  transfer  all 
the  needed  starting  arguments  to  the  called  routine. 

• A mechanism  must  be  provided  for  the  using  routine  to  obtain  the 
results  generated  by  the  called  routine. 

• A mechanism  must  be  provided  to  prevent  interruption  of  the  called 
subroutine  by  a program  which  will  call  the  same  subroutine,  or  else  conventions 
must  be  made  about  locating  the  input  and  output  lists  so  that  such  re-entry  is 
harmless. 

• Finally,  conventions  must  provide  a clear  understanding  as  to  which 
registers  the  called  subroutine  may  use  and  those  which  it  must  not  alter. 

The  extent  to  which  automatic  machine  aids  are  given  to  the  solutions 
to  these  problems  must  be  limited  to  the  absolute  minimum.  If  complex  machine 
aids  are  given,  they  inevitably  lead  to  more  programmer  problems  than  they  solve. 

The  minimum  usable  solution  is  the  existence  of  a "subroutine  transfer"  instruction 
which  stores  the  return  word  at  a location  specified  by  the  contents  of  a particular 
register,  say  Rl,  and  transfers  control  to  the  first  instruction  of  the  called 
subroutine  (specified  in  the  address  field  of  the  transfer  Instruction). 
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3-49 


The  calling  program  must  previously  have  stored  the  subroutine  input 


data  at  locations  (Rl)  + 1,  (Rl)  +2,  (Rl)  + K. 

The  called  subroutine  is  written  to  access  its  input  data  relative  to 
(Rl)  and  to  store  its  output  data  relative  to  (Rl)  consnencing  with  an  additional 
offset  of  K.  The  called  subroutine  is  terminated  with  a return  instruction  whose 
effect  is  to  transfer  control  to  the  instruction  addressed  indirectly  via  Rl  and 
to  restore  machine  status  from  the  non-address  field  portion  of  the  word  at  Rl. 

With  these  two  instructions  and  the  associated  programming  conventions 
it  is  entirely  possible  to  have  the  called  subroutine  interrupted  by  an  entirely 
different  program  which  later  calls  the  same  subroutines.  The  interrupting  program 
must,  or  course,  safestore  Rl  prior  to  using  it  as  the  link  to  the  different  region 
of  memory  which  it  uses  for  communication  with  the  subroutine. 

Memory  Relocation  Aids 

The  lEIS  software  is  structured  subject  to  the  assumption  that  the  com- 
puter system  includes  an  "independent"  l/O  controller  whose  function  is  to  attend 


to  the  step-by-step  minutiae  involved  in  transferring  lists  of  data  from  computer 
memory  to  or  from  the  peripheral  subsystems.  One  capability  that  could  be  incor- 
porated into  the  design  of  such  a controller  and  which  would  be  advantageous  to 
lEIS  (or  any  system  with  alphanumeric  display  requirements)  is  the  ability  to 
perform  autonomous  scatter-gather  operations.  In  the  lEIS  context,  the  problem 
arises  in  connection  with  operator  generated  requests  for  display  of  specific 
parameters.  The  sequence  in  which  such  requests  are  generated  is  completely 
unpredictable.  Thus,  at  the  end  of  each  data  acquisition  cycle,  it  is  necessary 
to  gather  the  current  values  of  a subset  of  the  instrument  data  scattered  in  a 
random  way  throughout  the  list  of  input  data,  and  output  these  to  the  display 
system  in  a suitably  edited  format. 
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The  main  program  can  attend  to  such  operator  generated  requests  by 
simply  entering  them  in  a "numeric  request  list."  The  bookkeeping  would  involve 
a record  of  where  the  end  of  the  list  is  in  memory.  On  new  requests  this  record 
is  augmented  and  the  new  request  stored  as  a pointer  to  its  position  in  the  loop- 
record.  (A  permanent  table  translating  operator  request  codes  to  parameter  position 
in  the  loop  record  is  required  for  this  purpose.)  On  erase  requests,  the  correspond- 
ing item  is  deleted  from  the  list.  The  last  item  in  the  list  is  transferred  to  the 
vacated  position  and  the  list  length  record  decremented. 

When  the  displayed  numeric  is  to  be  updated,  the  I/O  routine  can  now 
index  its  way  through  the  "numeric  request  list"  but  use  the  entries  therein  as 
indirect  references  to  the  parameter  value  list  in  the  loop-record.  The  request 
code  must  also  be  used  as  the  pointer  to  a "header"  list  to  generate  the  identifier 
text  for  the  display  and  take  account  of  the  effect  its  length  imposes  on  the  x- 
coordinate  of  the  displayed  numeric. 

The  important  feature  is  that  the  l/O  controller  should  be  able  to 
interpret  a variety  of  address  modifications  rather  than  the  customary  index  from 
a specified  base. 

If,  as  is  most  likely,  the  entire  lEIS  Programs  and  data  cannot  all  be 
simultaneously  in  main  core,  supervisory  control  will  frequently  encounter  the 
overlay  problem.  This  involves  transfer  of  parts  of  the  program  currently  needed 
but  presently  available  only  in  external  storage,  into  main-core,  thus  displacing 
some  part  of  the  program  presently  resident  in  core  but  (hopefully)  not  imnediately 
needed.  This  problem  is  somewhat  eased  by  permitting  only  block  transfers  of  fixed, 
uniform  size.  Such  block-oriented  transfers  can  be  inefficient  if  the  transferred 
segment  occupies  only  a fraction  of  the  block.  It  would,  occasionally,  be  desirable 
to  combine  the  contents  of  two  or  more  partially  occupied  blocks.  This  Involves  a 
memory-to-memory  relocation  of  a segment.  Rather  than  perform  this  operation  word- 
by-word,  using  the  supervisor  program  running  in  the  CPU,  it  would  be  desirable  to 
assign  the  actual  moving  to  the  I/O  controller  and  allow  the  process  to  be  completed 
while  the  CPU  is  free  to  perform  more  productive  tasks. 
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Micro-Diagnostics 

It  has  been  pointed  out  elsewhere  that  the  ability  of  a microprograiimed 
machine  to  perform  diagnostic  or  readiness  tests  at  the  microprogram  level  shrinks 
the  untestable  hard  core  from  roughly  75  percent  to  two  percent. 

Microstep  Maintenance  Aids 

We  have  found  that  mean  time  to  diagnose  a computer  malfunction  can  be 
drastically  reduced  if  the  maintenance  technician  has  at  his  disposal  the  ability 
to  cause  the  machine  to  advance  through  the  execution  of  any  Instruction  on  a micro- 
step by  micro-step  basis  with  the  entire  machine  state  displayed  following  each 
step. 

I/O  Echo  Checks 

Periodic  on-line  test  of  the  Integrity  of  data  transfers  Is  greatly 
enhanced  and  maintenance  diagnosis  facilitated  if  the  l/O  controller  can  be  directed 
to  repeat  (echo)  the  data  transferred  to  it.  Similar  benefits  accrue  if  transfers 
from  I/O  controller  to  device  controller  can  be  similarly  checked. 

Continuous  l/O  Error  Check 

Continuous  check  of  data  integrity  is  possible  if  all  l/O  transfers  have 
parity  generation/checking.  Limited  error  correcting  capability  is  possible  if 
orthognal  (bit  column)  parity  Is  generated/checked  on  all  multiword  transfers. 

These  features  are  testable  only  if  the  machine  has  a special  instruction  to  trans- 
mit words  with  erroneous  parity. 

I/O  Transfer  Emulation 

Software  diagnosis  is  facilitated  if  the  l/O  controller  is  able  to 
send  and  also  to  receive  and  check  "canned"  test  words  (with  and  without  correct 
parity) . 

I/O  Interrupt  Emulation 

Software  test  of  the  machine's  response  to  I/O  Interrupts  is  not  possible 
unless  instructions  are  available  to  generate  artificial  Interrupts. 
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3. 4, 2. 2,1  Comparison  of  Computers 


In  the  following  table,  we  con5>are  an  older  machine,  two  representative 
contemporary  machines  and  an  advanced  machine  relative  to  the  foregoing  list  of 
desirable  attributes  and  some  other  features  elsewhere  identified  as  desirable 
or  essential  to  the  lEIS  application.  The  old  machine  is  represented  by  the  CP 
901/ASQ-114,  a Navy  inventory  machine  manufactured  by  Univac.  Contemporary 
machines  are  represented  by  the  1602  Rugged  Nova  manufactured  by  ROLM  Corporation 
and  the  CP-32  manufactured  by  General  Electric.  The  advanced  machine  is  represented 
by  the  AADC  processing  element  which  is  currently  in  advanced  planning  stages  by 
Raytheon  Company.  The  known  computer  characteristics  are  compared  in  Table  3.4-1. 

3. 4. 2. 2. 2 lEIS/AADC  Architecture 
3. 4. 2. 2.2.1  AADC  Architecture 

The  AADC  is  a modular  computer  whose  elements  can  be  configured  in  a 
variety  of  processing  structures.  The  various  AADC  elements  are  described  below. 

The  DPE 

The  DPE  is  composed  of  a PMU  (Program  Management  Unit) , an  AP  (Arithmetic 
Processor),  a TM  (Task  Memory),  and  a Channel.  It  is  a general  purpose  processor 
capable  of  performing  all  operations  needed  for  processing  sequentially  organized 
tasks.  The  DPE  provides  a significant  improvement  in  processing  speed  and  efficiency 
through  the  use  of  a parenthetical  control  technique.  That  is,  a fewer  number  of 
program  instructions  will  be  needed  since  many  unnecessary  memory  loads  and  stores 
will  be  eliminated  and  memory  access  requirements  will  be  reduced. 

The  Task  Memory 

The  DPE  task  memory  consists  of  4K  words  of  storage,  36  bits  per  word 
and  is  used  to  store  program  segments  during  execution.  The  TM  is  also  used  for 
temporary  data  storage. 
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The  Arithmetic  Processor 

All  arithmetic  and  logical  computation  for  the  DPE  is  performed  in 
the  arithmetic  processor.  This  capability  includes  performing  array  operations, 
polynomial  manipulations,  vector  and  matrix  arithmetic,  complex  arithmetic, 
subroutine  operations,  and  bit,  byte,  halfword,  and  fullword  processing.  In 
addition,  the  AP  performs  arithmetic  operations  on  fixed  point,  floating  point, 
or  mixed  data  formats. 

The  DPE  PMU 

All  control  functions  of  the  DPE,  including  normal  instruction  and 
operand  fetching,  execution  of  program  management  type  instructions,  and  inter- 
facing with  other  elements  via  the  Main  Data  Bus  are  controlled  by  the  PMU.  It 
also  has  its  own  instruction  set  which  includes  arithmetic  and  logical  operations 
on  both  16  and  32  bit  operands. 

The  BORAM 

BCMAM  (Block  Oriented  Random  Access  Memory)  stores  procedure  and  con- 
stants for  all  programs  in  pages  of  256  words  each.  BORAM  is  completely  program- 
mable, with  an  off-line  write  time  of  about  2 milliseconds  per  256  word  page.  When 
accessed  by  a DPE,  BORAM  will  load  256  word  program  segments  into  the  TM.  As  the 
DPE  sequences  through  the  program  segments  (which  are  not  in  TM) , the  need  for 
another  page  of  the  program  resident  in  BORAM  may  arise  due  to  branching  needs 
or  end  of  resident  IM  page.  Other  program  pages  are  then  transferred  into  TM  on 
a demand  basis.  Transfers  from  BORAM  to  TM  are  via  the  Main  Data  Bus  at  an  un- 
interrupted rate  of  150  nsec  per  word.  A BORAM  page  transfer  to  TM  will  take 
approximately  42  microseconds. 

The  RAMM-PMU 

The  main  data  storage  for  the  system  is  the  RAMM  (Random  Access  Main 
Memory),  consisting  of  a series  of  memory  modules,  each  8K  or  16K  words  by  36  bits. 
A PMU  acts  as  the  RAMM's  "smart  front  end",  performing  all  RAMM  control  functions. 
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The  Bus 
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The  AADC  Bus  System  contains  two  Main  Data  Buses  and  an  l/O  Bus.  The 
Main  Data  Buses  are  bidirectional  Buses  which  provide  for  all  data  and  control 
information  transfers  between  the  various  AADC  elements.  Bus  transfers  occurs 
d'j''in3  a 150  nsec  time  slot.  An  element  that  desires  to  use  the  Bus  raises  an 
internal  demand  line,  and  awaits  notification  of  Bus  assignment  on  a rotational 
Bus  grant  priority  list.  Elements  having  no  demand  for  the  Bus  are  merely  skipped 
as  their  turn  arrives;  in  this  manner,  all  time  slots  are  used.  When  two  elements 
desire  to  communicate,  then  either  Bus  may  be  used,  depending  on  which  is  free. 

When  transmitting  information,  there  is  no  need  to  know  if  an  element  is  busy; 
small  input  queues  on  each  element  accept  data  and  hold  it  whether  the  element  is 
busy  or  not.  This  arrangement  eliminates  wasting  Bus  time  in  determining  whether 
a destination  device  is  busy  or  not. 

The  l/O  Bus  is  dedicated  to  I/O  functions  allowing  another  degree 
of  parallelism  in  the  AADC;  processor  transactions  continue  while  I/O  functions  are 
performed. 

The  Channel 

A channel  element  interfaces  each  of  the  AADC  elements  with  the  AADC  Bus 
System.  The  primary  function  of  the  channel  is  to  handle  source/destination  informa- 
tion, that  is,  to  ensure  that  information  traversing  the  Bus  is  accepted  by  a specific 
channel,  while  rejected  by  all  others.  Likewise,  a channel  must  appropriately  decide 
when  information  can  be  placed  in  a time  slot  on  the  Bus. 

Virtual  Addressing 

basic  feature  of  the  AADC  is  the  memory  addressing  scheme.  Addressing 
ts  parforaad  either  virtually  or  directly,  and  virtual  addressing  is  considered  Che 
•ere  prereleat  mode.  An  instruction  in  the  program  sequence  is  obtained  in  the 
'»«iiea  •Burner;  the  low  order  8 bits  of  the  DPE  Program  Counter  (PC)  specifies 
• •««#«•#  Che  pe«e.  an  8 bit  page  register  specifies  Che  present  active 
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page;  by  concatenating  these  two  fields,  a 16  bit  address  is  achieved;  and  the 
required  location  within  TM  can  then  be  reached  with  this  address.  If  a page  boundary 
is  crossed,  or  a branch  instruction  encountered,  a 16  bit  address  of  the  kernel  word 
is  formed  by  appending  the  upper  8 bits  of  the  PC  (called  the  kernel  word  address) 
to  the  8 bit  kernel  page  register  (two  variable  bits  preceded  by  six  ZEROS).  When 
that  kernel  word  is  located  in  TM,  the  residency  bit  is  checked.  If  this  bit  is 
set,  then  the  required  BORAM  page  is  already  resident  in  TM;  in  this  case,  the  8 
bit  new  page  address  located  in  the  kernel  word  is  used  to  find  the  next  instruction. 
Once  this  instruction  is  found,  the  virtual  process  for  acquiring  RAMM  data  is  again 
undertaken.  If  the  residency  bit  is  not  set  in  the  kernal  word,  then  a 20  bic  .>0RAM 
address  is  taken  from  the  kernal  word  and  sent  over  the  Bus  to  BORAM.  BORAM  sends 
the  proper  page  back  to  the  DPE,  and  places  it  in  TM.  The  location  of  page  placement 
depends  upon  which  pages  are  available  in  TM;  if  TM  is  filled  to  capacity,  replacement 
algorithms  determine  which  page  should  be  replaced.  When  this  page  is  found,  it  is 
written  over  with  the  new  page.  The  present  page  address  register  is  then  updated 
and  addressing  continues  as  described  above.  If  the  instruction  needs  data  on 
which  to  operate,  the  8 bit  kernal  word  location  field  (which  is  a part  of  the  in- 
struction word)  is  appended  to  the  8 bit  kernal  page  register,  to  form  the  kernal 
word  address  for  the  data.  If  the  data  is  page  oriented,  the  residency  bit  is  checked, 
and  the  addressing  sequence  is  essentially  the  same  as  described  above  for  procedure. 

If  the  data  is  word  oriented,  it  is  not  resident  (only  page  oriented  data  may  be 
stored  in  TM)  and  the  8 bit  displacement  field  of  the  instruction  is  added  to  the 
20  bit  RAMM  address  in  the  kernal  word.  The  result  is  used  to  access  the  correct 
RAMM  location.  The  data  is  operated  on  as  soon  as  it  is  received  from  the  main  data 
bus. 

Security 

The  virtual  addressing  scheme  serves  as  the  basis  for  the  security  system 
in  the  AAOC.  The  program  kernal  word  must  supply  RAM  addresses  in  order  to  obtain 

data  from  RAM.  Areas  of  RAM  which  are  not  permitted  access  by  a particular  program 
are  made  inaccessible  by  not  providing  an  address  for  this  area  in  the  kernal  word. 
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In  addition,  the  security  system  is  further  enhanced  by  providing  a 


read  and  write  protect  bit  within  the  kernel  word.  When  the  read-protect  bit  is 
set,  the  program  is  not  allowed  to  read  the  desired  information  from  memory  un- 
less permission  is  granted  by  the  system  master  executive.  An  attempt  to  read 
when  this  bit  is  set  will  result  in  a bypass  of  that  instruction.  Similarly, 
when  the  write-protect  bit  is  set,  the  program  cannot  write  into  the  indicated 
virtual  segment  until  permission  is  received  from  the  system  master  executive. 
3.4.2.Z.2.2  AADC  Configurations 

The  elements  of  the  AADC  can  be  used  to  fashion  a variety  of  processing 
structures,  however  three  basic  configurations  exist:  the  minicomputer  or  minimum 

configuration;  the  simplex  processor;  and  the  multiprocessor. 

The  AADC  minimum  configuration  (see  Figure  3.4-6)  consists  of  a RAMM 
(Random  Access  Main  Memory) , a PMU  (Program  Management  Unit) , and  a DCM  (Data 
Communicator  Module) . 

The  RAMM  constitutes  the  main  data  storage  for  the  system  and  has  a 
read-write  cycle  time  of  approximately  250  nsec.  The  PMU  contains  sufficient 
arithmetic  processing  capability  to  process  data  on  a stand-alone  basis  (as  a 
minicomputer).  In  addition,  the  PMU  controls  the  routing  of  incoming  and  outgoing 
information,  as  well  as  performing  other  controller  functions.  The  DCM  serves  to 
interface  the  RAMM-PMU  combination  with  up  to  64  peripheral  devices  of  many  types, 
including  another  AADC  system  and/or  a NTDS  (Naval  Tactical  Data  System)  device. 

The  DCM  can  communicate  in  a parallel  (Including  fullword,  halfword,  or  byte)  or 
serial  mode,  can  transmit  and  receive  information  simultaneously  and  can  store  a 
limited  amount  of  data. 

The  DPE  (Data  Processing  Element) , the  BORAM  (Block  Oriented  Random 
Access  Memory),  the  internal  Bus  system,  and  the  Channels  constitute  the  Simplex 
Processor /configuration.  This  system  is  unique  in  that  one  DPE  performs  processing, 
but  several  RAM's  and  BORAM's  are  accessible. 
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A multiprocessor  configuration  is  structured  with  numerous  DPE's  on 
the  internal  AADC  Bus  (See  Figure  3.4-7)  other  elements  such  as  RAMM's  and  BORAM's 
can  also  exist  in  any  quantity.  A maximum  of  256  elements  with  channels,  each 
element  containing  64K  words  of  memory  can  be  placed  on  the  internal  Bus. 

The  AADC  baseline  indicates  that  the  DFE  will  accept  procedure  from 
the  BORAM  and  data  from  the  RAMM.  Programs  will  be  executed  by  the  DPE  with  the 
results  stored  in  TM,  outputted  directly,  or  returned  to  RAMM.  All  communications 
between  two  AADC  elements  will  be  via  the  internal  Bus.  In  order  for  an  element 
to  communicate  on  the  Bus,  it  must  interface  through  a channel. 

3. 4. 2. 2 .2. 3 lEIS  Configuration 

It  is  assumed  that  the  AADC  configuration  for  an  AIDS  equipment  air- 
craft will  be  the  multiprocessor  configuration.  Therefore  the  lEIS 
program  storage  will  be  in  BORAM  while  the  working  storage  will  be  either  in  the 
RAMM  or  TM  depending  on  whether  or  not  the  data  is  needed  by  other  program  modules 
than  the  one  currently  operating.  Since  the  TM  is  always  available  only  BORAM 
and  RAMM  requirements  will  be  changed  to  lElS. 

Using  the  multiprocessor  configuration  requires  that  processing  time 
estimates  take  into  consideration  the  time  needed  to  move  pages  of  program  from 
BORAM  to  TM.  The  processing  speed  will  be  dependent  on  the  t}rpe  of  program  being 
executed  since  the  DPE  is  a combination  of  a PMU  and  an  AP.  The  FMU  will  execute 
the  control  sections  of  a program,  handling  data  movement  and  most  decision  instruc- 
tions while  the  AP  will  execute  the  arithmetic  routines.  The  PMU  runs  at  an  average 
speed  of  about  1 MOPS  while  the  AP  runs  at  2 MOPS. 

3 .5  lEIS  Display  Generator 

3.5.1  Display  Generator  Requirements 

A series  of  operations  must  be  performed  in  order  that  mapping  of 
information  from  the  level  of  the  lEIS  data  processor  to  the  human  level  on  the 
display  surface  can  be  accomplished.  The  display  generator  generally  will  perform 
the  following  functions  related  to  this  transformation: 
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FIGURE  3.4-7  AADC  MULTIPROCESSOR 
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• Display  Data  Base  Storage 

• Character  Generation 

• Vector  Generation 

• Display  Formatting 

• Refresh  Storage 

• Digital  to  Analog  Conversion 

• Display  Control  (XYZ) 

Some  or  all  of  these  functions  could  be  performed  in  data  processor 
and  several  architectures  are  developed  in  subsequent  sections  to  examine  the  trade- 
offs of  processor  - I/O  utilization  and  display  generator  complexity. 

3.5.2  Display  Generator  Architectures 

3. 5. 2.1  Random  Position  Beam  Control  Architectures 

The  first  type  of  display  generator  to  be  considered  is  a display  genera- 
tor employing  a random  access  local  memory  and  the  random  position  method  of  beam 
control.  A block  diagram  for  this  type  of  display  generator  is  shown  in  Figure 
3.5-1.  This  type  of  display  generator  was  employed  in  the  lEIS  Demonstration 
Equipment  developed  during  Phases  I and  II  of  the  lEIS  Contract. 

This  display  generator  uses  coded  display  instructions  stored  in  the  RAM 
to  control  the  x,  y and  z Inputs  to  the  CRT.  The  display  information  is  initially 
loaded  into  the  RAM  via  the  external  address  and  external  data  Inputs  from  the  bus 
interface.  Once  the  RAM  is  loaded,  display  refresh  is  accomplished  under  local  control. 
For  each  frame  the  timing  generator  first  initializes  the  address  counter  and  then  in- 


crements the  address  to  sequentially  read  the  display  instructions  from  the  RAM.  Dis- 
play elements  such  as  alphanumeric  characters  and  line  segments  are  produced  in 
response  to  the  decoded  display  instructions,  until  an  end  of  frame  instruction  is 
decoded.  Upon  execution  of  the  end  of  frame  instruction  the  display  generator  is 
idle  until  the  start  of  the  next  frame.  During  the  idle  period  the  memory  is  available 
for  updating  by  the  CPU.  Since  the  display  information  is  stored  as  coded  display 
Instructions  many  updates  will  Involve  changing  only  a small  number  of  words  in  the 
RAM.  The  l/O  bus  loading  for  this  method  of  display  generator  is  therefore  very  light. 
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Figure  3.5-1  DISPLAY  GENERATOR  WITH  RANDOM  ACCESS  LOCAL  MEMORY 
AND  RANDOM  POSITION  METHOD  OF  BEAM  CONTROL 
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Figure  3.5-2  shows  a variation  of  the  random  position  display  generator 
in  which  the  local  memory  has  been  eliminated.  In  this  case  the  CPU  must  supply 
control  codes  to  the  display  generator  at  a rate  consistent  with  the  instruction 
execution  cycle.  Although  this  method  of  display  generation  results  in  a sizable 
increase  in  l/O  traffic,  the  processor  utilization  and  memory  requirements  are  not 
significantly  increased  over  the  case  employing  a local  memory. 

The  next  logical  step  in  simplifying  the  display  generator  hardware 
while  employing  the  random  position  method  of  beam  control  is  the  extreme  case 
where  the  bus  interface  is  connected  directly  to  the  x,  y and  z registers.  The 
CPU  must  now  supply  fully  decoded  position  and  intensity  information  at  a rate 
consistent  with  the  CRT  dot  control  circuits.  Operation  in  this  mode  will  impose 
very  high  loads  on  both  the  l/O  and  the  processor. 

3. 5. 2. 2 Raster  Scan  Beam  Control  Architectures 

The  block  diagram  for  a display  generator  based  on  the  raster  scan  method 
of  beam  control  and  employing  a shift  register  refresh  memory  is  shown  in  Figure 
3.5-3.  The  architecture  employs  three  levels  of  storage.  The  first  level  of  storage 
is  random  access  and  contains  the  display  list,  that  is,  the  list  of  display  codes 
that  completely  define  the  display  content.  This  display  list  can  be  identical  to 
the  display  codes  used  in  the  random  position  method  of  Section  3. 5. 2.1,  thus  the 
functioning  of  the  central  processor  would  be  the  same.  The  utilization  of  the 
display  codes  is  considerably  different  in  this  case,  however,  since  all  the  display 
information  must  be  formatted  into  a bit  pattern  which  can  be  synchronized  with  the 
raster.  In  order  to  accomplish  this  formatting  the  second  level  of  storage  is  used. 
This  storage  is  also  random  access  and  may  physically  be  part  of  the  same  memory 
structure  used  for  the  display  list.  Distinction  is  made  because  this  level  of 
storage  is  accessed  only  by  the  display  generator.  In  operation,  the  display  gen- 
erator decodes  the  instructions  in  the  display  list  and  by  applying  conversion 
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FIGURE  3.5-2  DISPLAY  GENERATOR  WITH  RANDOM  POSITION  BEAM 
CONTROL  AND  NO  LOCAL  MEMORY 
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FIGURE  3.5-3  DISPLAY  GENERATOR  WITH  RASTER  SCAN  BEAM 

CONTR»/i.  AND  THREE  LEVELS  OF  LOCAL  STORAGE 
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algorithms  or  by  drawing  on  bit  pattern  information  stored  in  ROM  (for  characters) 
a bit  pattern  is  generated  that  matches  the  intensity  versus  time  function  required 
for  controlling  the  z input  to  the  CRT.  Once  the  proper  bit  pattern  has  been 
assembled  in  RAM  it  is  transferred  to  the  third  level  of  storage,  that  is,  the 
refresh  shift  register. 

The  refresh  shift  register  recirculates  in  synchronism  with  the  raster 
timing  and  thus  is  the  only  portion  of  the  display  generator  besides  the  raster 
generator  that  must  continuously  operate  at  the  frame  rate.  The  three  levels  of 
storage  allow  each  section  of  the  display  generator  to  operate  asynchronously. 

The  display  list  RAM  can  be  loaded  at  a rate  consistent  with  the  data  bus  capacity. 
The  bit  pattern  generator  will  operate  at  a slower  rate  since  the  only  concern  here 
is  for  the  introduction  of  latency  thus  the  capability  to  process  a complete  display 
format  change  in  less  than  100  ms  is  adequate.  Once  the  required  bit  pattern  has 
been  constructed  in  RAM  it  can  be  transferred  to  the  shift  register  in  one  frame 
time. 

Once  the  initial  loading  of  the  shift  register  has  been  accomplished, 
display  update  requires  only  that  those  display  codes  involved  in  the  update  be 
reprocessed  and  that  the  shift  register  be  selectively  reloaded. 

A variation  of  the  display  generator  just  described  can  be  conceived 
where  the  display  list  RAM  is  eliminated.  The  effect  of  this  change  would  be  to 
require  that  the  transfer  of  display  codes  from  the  central  processor  by  S3rnchronized 
with  the  operation  of  the  bit  pattern  generator.  The  actual  data  transferred  would 
not  change  so  the  processing  required  is  the  same.  The  I/O  control  would  be  more 
complex  however,  since  a means  of  providing  for  the  proper  timing  of  code  transfers 
would  be  required.  A common  means  of  handling  this  type  of  data  transfer  control 
is  through  the  use  of  interrupts.  The  display  generator  would  send  an  interrupt  to 
the  central  processor  whenever  it  is  ready  to  accept  a new  display  code  input. 
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The  central  processor  would  respond  to  the  interrupt  either  by  sending  a 
new  display  code  or  if  no  display  update  is  immediately  needed  Che  central  processor 
would  simply  remember  that  Che  display  generator  is  ready  Co  receive  updated  codes 
so  chat  when  the  need  for  a display  change  occurs  Che  new  display  code  can  be  sent 
immediately. 

The  function  of  the  bit  pattern  generator  can  be  accomplished  either  by 
special  purpose  hardware  or  by  programmed  processor.  This  function  could  be  performed 
by  the  central  processor  if  the  increase  in  processor  utilization  can  be  tolerated. 
With  this  approach  data  from  the  bus  interface  would  be  loaded  directly  into  the 
shift  register  with  no  more  than  a two  word  buffer  required. 

The  ultimate  reduction  in  display  generator  hardware  would  result  if  the 
shift  register  were  reduced  in  length  to  equal  the  word  length  of  the  data  received 
from  the  data  bus.  In  this  case  Che  shift  register  would  not  recirculate  but  would 
be  reloaded  by  parallel  entry  from  Che  data  bus  each  time  a word  is  shifted  out. 

This  scheme  would  result  in  the  highest  I/O  bus  utilization  of  any  display  generator 
architecture  considered. 

The  AADC  resource  requirements  for  the  above  display  generator  architecture 
are  addressed  in  Section  2.2.4  of  the  Phase  IV  Final  Report. 

Although  Che  raster  scan  architectures  described  above  were  shown  to 
produce  separate  x,  y and  z Inputs  to  the  display  in  order  to  maintain  similarity 
between  these  and  the  random  position  schemes  it  may  in  some  instances  be  desirable 
Co  consider  the  raster  generator  as  part  of  the  display  rather  chan  part  of  Che  dis- 
play generator.  In  this  case  Che  x and  y lines  would  be  replaced  by  Che  sync  line 
as  a display  generator  output  or  if  the  number  of  interface  lines  were  to  be  minimized 
at  the  ex^.onse  of  additional  hardware  the  sync  and  intensity  (z)  signal  could  be  com- 
bined into  a composite  video  signal  similar  Co  a conventional  TV  signal.  The  choice 
between  these  variations  requires  consideration  of  the  comparative  complexity  of 


the  display  switch  versus  the  signal  combining  and  sync  separation  circuits. 
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3.5.3  AADC  Application  to  Display  Generation 

^.5 .3.1  AADC  Resource  Estimates  for  Display  Generation 

In  this  section  the  AADC  resources  required  for  each  of  the  display 
generator  architectures  described  in  Section  3.5.2  is  presented.  In  order  to 
simplify  reference  to  the  various  architectures,  Table  3.5-1  has  been  constructed 
assigning  each  an  arbitrary  Type  #.  The  program  module  that  is  hardware  dependent 
is  the  Display  Editor.  The  other  display  modules,  that  is,  the  Display  Feature 
Base  and  the  Display  Feature  Select  modules  are  not  affected  by  the  display  generator 
architecture. 

The  baseline  resource  estimate  was  made  for  the  case 
where  the  display  generator  architecture  minimizes  the  processor  requirements,  that 
is,  t}q>es  1 and  4.  The  other  estimates  are  made  relative  to  this  baseline  and 
indicate  a relative  complexity. 

The  following  assumptions  were  made  in  calculation  of  the  baseline 
resource  requirements: 

• All  execution  is  done  in  a Program  Management  Unit  (PMU)  at  a 
I MOPS  rate. 

• Display  updates  are  required  at  an  average  rate  of  1 per  second. 

• Each  update  requires  changing  10  display  codes  with  the  execution 
of  10  instructions  required  for  each  code  change. 

• I/O  bus  capacity  is  320  MBPS. 

For  the  display  generator  architectures  requiring  direct  refresh  the 
following  additional  assumptions  were  made: 

• Refresh  rate  is  50  frames  per  second. 

• Display  resolution  is  256  x 320 


I 

I 

I TABLE  3.5-1 

I Type  // 

1 

2 

3 

I 4 

I 

I 


DISPLAY  GENERATOR  ARCHITECTURES 


Deacrlptlon 

Random  position  beam  control,  local 
memory,  coded  Inputs. 

Random  position  beam  control,  no  local 
memory,  coded  Inputs. 

Random  position  beam  control,  no  local 
memory,  fully  decoded  Inputs. 

Raster  scan,  display  list  storage,  coded 
Inputs . 

Raster  scan,  no  display  list  storage, 
coded  Inputs. 

Raster  scan,  refresh  storage  only,  fully 
decoded  Inputs. 

Raster  scan,  no  refresh  storage,  fully 
decoded  Inputs. 


k 


Table  3.5-2  presents  the  resource  estimates  for  each  type  of  display 
generator  considered  in  Section  3.5.2.  As  can  be  seen  a rather  wide  range  of 
processor  utilization  and  I/O  bus  loading  is  represented.  The  very  high  processor 
utilization  for  Type  3 and  7 arises  from  the  assumption  that  the  complete  display 
is  regenerated  each  frame.  This  means  that  no  refresh  memory  exists  either  in 
the  display  generator  or  in  the  central  computer  and  the  full  burden  of  display 
refresh  is  placed  on  the  processor.  This  high  utilization  could  be  reduced  to 
1-2%  by  providing  refresh  memory  in  the  RAMM  but  the  other  alternative  was  chosen 
to  illustrate  the  extreme  case. 

3. 5. 3. 2 Use  of  AADC  Hardware  Modules  for  Display  Generation 

The  75%  processor  utilization  that  results  from  requiring  the  display 
refresh  to  be  handled  by  a processor  suggests  that  this  would  be  a reasonable  task 
for  a dedicated  processor.  With  the  assumption  that  all  Instructions  executed 
by  the  Display  Editor  would  be  PMU  instructions,  to  consider  building  a display 
generator  which  contains  a PMU  that  will  perform  all  the  processing  required  to  refresh 
the  display  operating  directly  from  a coded  display  list  is  possible.  All  storage 
requirements  for  the  display  generator  can  be  accommodated  by  an  AADC  Task  Memory. 

This  approach  is  applicable  to  either  the  random  position  or  raster  scan  methods  of 
beam  control.  A generalized  block  diagram  for  a display  generator  utilizing  AADC 
hardware  modules  is  shown  in  Figure  3.5-4. 
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FIGURE  3.5-4 

DISPLAY  (XNERATOR  USING  AADC  MODULES 
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3.5.4  Display  Generator  Conclusions  and  Reconanendations 

The  display  generator  Investigation  has  shown  that  the  AADC  Is  capable 


of  supporting  a wide  variety  of  display  generator  architectures  even  to  the  extent 
of  requiring  the  processor  to  refresh  the  display  directly.  The  tradeoff  between 
processor  loading  and  external  hardware  complexity  usually  Indicates  that  the 
computer  should  handle  as  much  work  as  possible.  However,  operational  experience 
with  systems  employing  computers  has  shown  that  over  the  life  of  a system  the  proces- 
sing requirements  tend  to  Increase  with  Improvements  In  system  capability.  Vlhen 
the  processing  requirements  begin  to  exceed  the  hardware  resources  available, 
expensive  hardware  retrofits  become  necessary.  For  this  reason,  functions  like 
display  refresh  should  be  handled  by  external  hardware  rather  than  by  the  central 
processor  even  though  Initial  studies  might  indicate  that  the  processor  could 
accomplish  the  function. 

I/O  bus  loading  tends  to  be  a direct  function  of  the  processor  loading. 
As  the  amount  of  work  done  by  the  central  processor  increases  the  amount  of  data  that 
must  be  transferred  over  the  l/O  bus  also  increases.  The  use  of  external  display 
generator  hardware  relieves  the  bus  loading. 

The  use  of  AADC  hardware  modules  In  the  display  generator  depends  on 
two  factors.  First,  can  the  module  perform  the  function,  and  second,  does  efficient 
use  of  the  module  result.  In  the  case  of  using  an  AADC  Program  Management  Unit  (PMU) 
as  the  major  portion  of  the  display  generator  hardware,  the  answer  to  both  questions 
Is  "yes"  with  the  qualification  that  the  display  generator  be  structured  such  that 
the  PMU  accepts  a coded  list  of  display  Instructions  and  processes  the  list  on  a 
real  time  basis.  An  architecture  In  which  the  PMU  Is  used  Just  to  restructure  the 
display  Information  for  a refresh  memory  would  result  In  under-utlllzatlon  of  the 
PMU.  To  be  efficient  the  PMU  must  be  forced  to  regenerate  the  full  display  each 
frame.  This  approach  is  reasonable  in  that  the  amount  of  memory  required  in  the 
display  generator  Is  minimized.  A 4K  Task  Memory  is  sufficient  for  the  display 


I 

I 

I 


generator. 
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The  reconmended  approach  to  display  generation  Is  therefore  to  employ 
AAOC  modules,  specifically  the  PMU  and  TM  modules,  which  will  operate  from  a coded 
display  list  stored  in  the  TM.  The  resources  required  for  the  central  processor 
will  be  those  shown  in  Table  3.5-2  for  display  generators  Type  #1  or  4. 

3.6  lEIS  Display 

3.6.1  Display  Requirements 

The  Phase  IV  display  investigation  consists  of  a review  of  the  principle 
display  media  which  were  identified  as  lEIS/AIDS  contenders.  The  primary  require- 
ments are  listed  in  Figure  3.6-1 

3.6.2  Display  Technology  Survey 

A survey  of  technology  applicable  to  the  lEIS  Display  was  conducted 
du. g Phase  IV.  Figure  3.6-2  lists  the  lEIS  display  parameters  discussed  in  Section 
3.6.1  in  the  first  column  on  the  left  side  of  the  table  and  the  lEIS  requirements 
for  these  parameters  in  the  third  column.  In  the  second  column  is  a list  of  numbers 
from  1 (most  critical)  to  10  (least  critical)  which  indicates  the  relative  performance 
value  assigned  to  each  of  the  lEIS  parameters. 

Across  the  page  from  left  to  right  are  listed  the  display 
media  which  are  most  likely  contenders  for  the  lEIS  display  application.  The 
display  media  considered  were  monochrome  cathode  ray  tubes,  color-cathode  ray  tubes  - 
voltage  penetration,  light  emitting  diodes,  liquid  crystal,  digisplay,  DC  plasma 
panel,  and  AC  plasma.  By  scanning  the  rows  and  columns,  comparisons  can  be  quickly 
made  between  the  various  display  media  and  the  lEIS  requirements. 

Experience  has  demonstrated  the  fact  that  no  display  Is  best  qualified  to 
satisfy  all  requirements  and  that  investigation  and  analyses 

are  necessary  in  order  to  properly  choose  a display  unit  and  Integrate  it  with  a system. 
The  approach  taken  in  the  technology  survey  is  to  specify  selected,  fixed, 
guidelines  relating  the  lEISAlDS  parameters  and  then  fully  evaluate  the  contenders 
against  these  guidelines.  All  of  the  reviewed  displays  satisfied  some  of  the  parameters. 
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1)  Size  of  display  viewing  surface  5" (I 

2)  Maxlmiim  display  cavity  size  12"> 

3)  Maximum  viewing  distance  28" 

4)  Minimum  viewing  distance  12" 

5)  Resolution:  Must  match  320  X 256  screen  matrix 

: 50  to  60  Dots/inch 

Dot  Matrix:  Minimum  5X7  dot  matrix/ character 

Raster  Scan:  Min.  10  TV  lines /character 

6)  Character  Size:  3/16"  (Height) 

7)  Color:  Monochrome 

If  Color:  Minimum  of  3 colors.  (Red,  Yellow,  Green) 

8)  Grey  Scale:  None  required.  (Only  normal  level  and  intensify) 

9)  Ambient  Light  Level:  10,000  Ft.-cdls.  Maxlminn 

10)  Contrast  Ratio:  2:1  (Min.)  at  10,000  Ft.-cdls. 

11)  Display  Brightness:  100  Ft.  - Lbts.  (Min.) 


5" (H)X7"(V) 
12"X8"X8"  3/4  Ft. 3 


12)  MTBF: 


3000  Hours 


13)  Power  (Average): 


100  Watts 


FIGURE  3.6-1  lEIS  DISPLAY  PARAMETERS 
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Figure  3.6-2  Display  Matrix  Table 


but  did  not  fully  measure  up  to  the  guidelines.  The  more  times  a display  falls 
below  the  set  requirements,  the  more  the  display  will  have  to  be  Individually 
tailored  to  meet  the  lElS/AIDS  parameters. 


I 

I 

I 

! 


1 


The  key  problem  areas  associated  with  the  display  media  are  discussed 
below.  For  a complete  discussion  of  the  characteristics  of  each  media,  refer  to 
the  Phase  IV  Final  Report,  Sections  3.2.2  through  3.2.6. 

Large,  light  emitting  diode  displays  continue  to  have  many  problem 
areas.  Wafers  of  the  size  necessary  for  large  displays  are  not  available  as  single 
crystals.  Piecing  together  small  (1"  x 1")  wafers  creates  the  problem  of  electrically 
accessing  all  of  the  diodes.  High  power  consumption  in  the  display  and  drive  circuits 
cause  further  problems.  Also,  brightness  levels  are  often  inadequate.  Work  is  neces- 
sary in  the  area  of  reducing  drive  current  requirements  while  at  the  same  time  increasing 
brightness  levels. 

The  liquid  crystal  display  has  certain  key  problem  areas.  The  scan 
and  drive  circuitry  required  to  accomplish  the  lEIS's  requirements  is  extremely 
complex  in  nature.  The  temperature  "window"  in  which  the  device  must  operate  is 
a limiting  condition.  The  future  of  military  spec'd  liquid  crystal  displays  are 
highly  uncertain,  aue  to  this  temperature  "window".  Brightness  and/or  contrast  is 
greatly  dependent  on  the  viewing  angle  in  the  reflective  mode.  In  the  transmissive 
mode,  high  ambient  levels  will  greatly  effect  the  contrast  ratio. 


I 


I 


I 
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The  future  of  the  Digisplay  panel  is  very  unclear.  Release  as  a 
conanercial  product  and  not  as  an  avionic  display  is  likely  in  the  future.  The 
low  brightness  level  of  the  Digisplay  panel  is  also  an  area  of  prime  concern,  as 
well  as  its  high  power  consumption  levels.  The  size  of  a display  generator  to 
drive  the  Digisplay  in  the  lEIS  "mode"  would  be  another  sensitive  region. 

The  AC  plasma  panel  suffers  from  a serious  brightness  problem,  lack 
of  adjustment  of  the  brightness  level,  poor  contrast  ratio,  and  lack  of  selective 
editing,  which  for  lEIS  is  important.  The  size  requirements  of  a total  AC  plasma 
panel  and  display  generator  exceeds  the  lEIS  specs.  Similarly,  the  DC  plasma  panel 
is  greatly  hampered  in  many  of  the  same  areas  as  the  AC  plasma  panel.  But,  the 
brightness  and  contrast  ratio  is  better  than  the  AC  panel,  while  the  uniformity 
of  brightness  across  the  panel  is  poor.  The  chances  of  mil  spec  units  are  poor. 

The  voltage  penetration  CRT's  have  problems  with  the  brightness  and 
the  contrast  ratio.  The  efficiency  of  the  red  phosphor  is  much  below  that  of  the 
green  phosphor,  causing  the  need  for  complex  circuit  design  to  compensate  for  this 
discrepency.  High  switching  voltages  required  to  produce  red,  yellow  and  green 
displays,  one  color  at  a time,  also  requires  a higher  order  of  circuit  design. 

The  high  voltage  components  of  the  power  supply  are  greatly  effected  by  this  high- 
voltage  switching,  causing  the  shortening  of  their  useful  life  and  reduction  of 
the  MBTF . A prominent  manufacturer  of  cathode  ray  tubes  dropped  the  development 
of  the  voltage  penetration  tube  for  avionic  application  primarily  because  of  the 
phosphor,  switching,  and  brightness  problems  described  above.  They  still  produce 
voltage  penetration  tubes,  but  mainly  for  computer  display  applications.  Of  all 
the  display  media  reviewed,  only  this  one  has  color  capability. 
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The  monochrome  cathode  ray  tube  has  had  the  highest  level  of  development, 
and  the  greatest  financial  outlay  for  its  research  and  development,  of  any  display 
covered  by  this  report.  This  situation  exists  because  the  CRT  has  been  on  the  scene 
for  more  than  fifty  years,  and  technical  understanding  has  reached  a level  not 
approached  by  the  other  listed  displays.  Most  of  the  IEIS/aIDS  parameters  can  be 
met  and  in  many  cases  exceeded  by  the  CRT.  The  weak  areas  are  the  contrast  ratio 
in  sunlight  and  the  fixed  supply  voltages.  The  monochrome  cathode  ray  tube  in  either 
the  raster  scan  mode  or  random  scan  mode  are  almost  identical  to  each  other  when 
mirrored  against  the  IEIS/AIDS  parameters,  save  for  two  exceptions.  First  the 
linear  sweeping  circuits  are  more  involved  in  the  random  scan  mode.  Second,  the 
raster  scan  display  generator  circuitry  is  not  as  simple  as  the  display  generator  for 
the  random  scan.  Solid  state  memory  technology  advances  are  improving  the  latter 
problem. 

In  conclusion  the  recommendations  are  twofold.  One,  the  immediate 
choice  for  an  lEIS  display  is  a cathode  ray  tube.  Two,  carefully  monitor  other 
technologies  to  consider  them  for  implementation  into  AIDS  when  their  deficiencies 
are  sufficiently  reduced. 

3 .7  Keyboard 

The  method  by  which  the  flight  crew  interrogates  the  lEIS  will  be  a 
part  of  an  integrated  "keyboard"  which  will  service  all  AIDS  functions.  Furthermore 
an  advanced  technology  approach  resulting  in  programmable  push  buttons  will  be 
implemented.  The  keyboard  described  below  is  the  approach  taken  for  the  lEIS  Display 
System  Evaluation  Equipment  which  allowed  interactive  evaluations  to  be  performed. 
Although  this  equipment  was  fabricated  in  1971  and  does  not  presently  represent  the 
state-of-the-art,  some  insight  into  lEIS  input  requirements  can  be  obtained. 
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The  keyboard  used  in  the  Display  System  Evaluation  Equipment  is  shown 
in  Figure  3.7-1.  This  keyboard  provides  the  means  for  the  pilot  to  interact  with 
the  display  and  it  also  serves  as  a display.  Whenever  a function  is  selected, 
the  legend  cap  of  the  push-button  switch  for  that  particular  function  will  light. 

In  this  way,  the  keyboard  serves  as  an  indicator  as  to  what  modes  are 
currently  being  displayed. 

A brief  description  of  the  keyboard  functions  defined  for  the  evaluation 
equipment  is  given  below. 

1 . Parameter  Display 

This  group  of  seven  (7)  switches  perform  the  following  functions : 

• Main  Eng.,  Fuel/Cont. , Lub.,  Elec.,  and  Mech,  - Five 
individual  switches  each  representing  a sub-group, 
used  to  select  the  parameters  within  their  respective 
subgroups  for  display  in  the  parameter  display  area 
of  the  lEIS  display, 

a Prime  Parameter  - A single  switch  used  to  select  the 
"Prime  Parameter"  display  for  display  in  the  parameter 
display  area. 

• Vertical  Format  - A single  switch  used  to  select  Engine 
Performance  Factor  or  the  four  eligible  parameters  for 
vertical  display  in  the  engine  performance  factor  display 
area.  This  switch  is  cycled  to  get  the  desired  display, 
that  is,  the  pilot  would  depress  it  each  time  he  wanted 
the  display  to  change.  His  indication  of  the  position 

of  the  switch  would  be  by  the  title  of  the 
display  in  the  engine  performance  factor  area.  The  switch 
will  require  the  following  (6)  positions;  Off;  Engine 
Performance  Factor;  and  four  parameter  positions. 
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2.  Energy  Management  Display 


A group  of  five  (5)  switches  are  used  for  the  following 
functions ; 

• Take  Off  - used  to  select  the  takeoff  display. 

• Time  Climb  - used  to  select  the  time  climb  energy 
management  display. 

• Fuel  Climb  - used  to  select  the  fuel  climb  energy 
management  display. 

• Range  Cruise  - used  to  select  the  range  cruise  energy 
management  display. 

• Endurance  Cruise  - used  to  select  the  endurance  cruise 
energy  management  display. 

The  pilot  selects  the  desired  mode  by  depressing  the  appropriate 
switch.  Only  one  mode  can  be  selected  at  a time  with  the  excep- 
tion of  the  "Climb"  modes.  The  climb  modes  can  be  selected 
while  the  takeoff  mode  is  being  displayed.  The  display  will  not 
change  to  the  appropriate  climb  display  until  the  aircraft  is 
off  the  ground  and  the  wheels  are  stowed.  To  remove  a mode  that 
is  currently  being  displayed,  the  appropriate  switch  is  depressed 
again. 

3.  Aircraft  (A/C)  Performance 

These  two  switches  are  used  to  select  for  display,  either  the  a/C 
performance  plot  without  afterburner  (W/O  A/B)  or  the  A/C  perform- 
ance plot  with  dropped  stores  (DROPPED  STORES). 

To  select  for  display  the  desired  switch  is  depressed;  to  remove, 
the  same  switch  is  depressed  again. 
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4.  Manual 


1 


I 

I 


I 

I 


These  three  pushbutton  switches  and  one  toggle  switch  are  used 
by  the  pilot  to  manually  enter  altitude,  mach,  or  time  Information 
Into  the  energy  management  program.  This  feature  allows  the 
pilot  to  select  altitude,  mach.,  or  time  values,  enter  the 
values  Into  the  computer  and  observe  on  the  display  what 
"Margins"  (miles  and  time)  he  will  have,  based  on  these  Input- 
ted values.  It  allows  the  pilot  to  know,  beforehand,  what  his 
margins  would  be  If  he  flew  at  a non-optimum  cruise  path. 

To  enter  altitude,  the  "ALT"  button  Is  depressed  which  indicates 
a manual  altitude  entry  Is  going  to  be  made  and  a readout  of 
altitude  appears  In  the  data  block  of  the  energy  management 
display. 
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The  count  button  is  set  to  "up",  which  causes  the  altitude 
readout  to  start  counting  upward  In  increments  of  100  feet. 

A two-speed  position  switch  commands  a slow  count  rate 
or  a fast  count  rate.  The  pilot  watches  the  read- 
out on  the  display;  when  the  desired  altitude  Is  shown  on  the 
readout,  he  stops  the  counter  (sets  "COUNT"  at  center  position) 
and  enters  the  data  into  the  program  by  pressing  the  "ALT" 
button  again. 


To  enter  mach.  or  time,  the  same  procedure  Is  followed,  except 
the  "Mach"  or  "Time"  button  Is  used  and  the  counter  counts  in 
Increments  of  .1  Mach  for  mach  and  1 second  for  time.  The 
"Down"  count  position  causes  the  counter  to  reverse  and  has 
two-speeds,  the  same  as  "up". 
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4.0 


DISPLAY  ENGINEERING/HUMAN  FACTORS 


4.1  INTRODUCTION 

The  display  engine erlng/human  factors  efforts,  for  the  lEIS  Program,  have  been 

concerned  with  defining  the  pilots  infonnation  requirements  and  the  formulation 

of  these  information  needs  into  usable  display  formats.  To  accomplish  these 

tasks  the  human  factors  efforts  during  the  earlier  phases  of  the  program  were 

concerned  with  information  analysis  and  display  formatting,  while  the  later 

phases  have  been  concerned  with  format  modification  and  evaluation.  This 

human  factors  effort  has  been  an  iterative  process  with  each  succeeding  phase 
» 

modifying  the  results  of  the  previous  phase. 

4.2  DISPLAY  ENGINEERING 

The  htsnan  factors  efforts  initially  were  conceimed  with  information  analysis, 
display  concept  formulation  and  initial  display  format  definition. 

A display  philosophy  was  established  which  consisted  of  the  following  criteria: 

• An  integrated  display  is  desirable  wherever  possible. 

e Display  only  that  information  which  is  necessary  for  that  particular  phase 
of  the  mission. 

e That  information  which  is  not  necessary  for  that  particular  phase  of  the 
mission  should  be  available  upon  the  request  of  the  pilot, 
e Qnergency  information  should  be  displayed  automatically, 
e Pilot  interpretation  should  be  avoided  whenever  possible, 
e Good  human  factors  engineering  display  criteria  will  be  applied.. 

An  information  analysis  was  conducted  using  Decislon>Action-Diagranming  as  the 
analytical  tool.  This  program  identified  the  pilots  informational  needs  for  the 
different  mission  segments  and  the  display  frequency  for  this  information. 
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The  information  analysis  provided  inputs  for  the  display  format  effort.  How.- 
ever  to  effectively  design  a group  of  display  formats  that  would  present  all 
the  required  information  in  a usable  form,  using  sound  human  engineering 
principles,  and  be  compatible  with  physical  constraints  required  information 
from  many  sources.  Figure  4.2-1  is  a tree  chart  of  the  various  inputs  that  were 
used  in  the  design  of  these  formats. 


•DISPLAY 

FORMATS 


DISPLAY 

modes 


FIGURE  4.2-1  Design  Information  Flow-IEIS  Display 
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A major  input  was,  of  course,  the  engine  parameters  that  were  monitored  by 
the  diagnostic  system.  These  parameters  were  weighted  to  determine  which  should 
be  available  for  display  to  the  pilot.  This  basis  for  weighting  parameters  was 
provided  by  pilot  ranking  of  the  Informational  content  of  each  parameter.  The 
parameter  list  and  the  sub-grouping  of  these  parameters  are  shown  In  Table 
4.2-1. 

The  Informational  analysis  determined  that  the  lEIS  display  should  have  che 
following  three  (3)  informational  modes; 

Continuous  - Information  that  Is  displayed  during  all  mission  segments 

On  Demand  - Information  that  Is  displayed  upon  pilot  request 

Automatic  - Information  that  Is  displayed  automatically  as  needed,  based 

on  mission  segment,  or  In  case  of  an  emergency  (malfunction). 

At  the  conclusion  of  the  Phase  IV  effort  the  reconmended  lEIS  display  concept 
consisted  of  these  three  Informational  modes,  with  each  presenting  specific  Infor- 
mation, as  follows: 

• Continuous  Data  Display 
Status  Bar 
RFM  Vertical  Scale 
THRUST  Vertical  Scale 
e Automatic  Data  Display 
Marginal  Malfunction 
Critical  Malfunction 
Self  Test 
Start 

e Manual  Data  Display 

Energy  Management  Mode 
Normal  Parameter 


Special  (Air  Start,  Data  Entry,  etc.) 
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rAitv!r  ri:R  list  with  Aniu<i:viATioNS 


M.MN  ENGINE 


• 

Low  Pressure  Compressor  Rocor  Speed 

N1  RPM 

High  Pressure  Turbine  Blndc  Tuinperacure 

TBT 

Core  Engine  Rotor  Speed 

N2  RPM 

Main  Fuel  Flow 

FF 

. 

Stall  Margin 

STALL 

High  Pressure  Compressor  Internal  Bleed  Flow 

INTFLW 

High  Pressure  Compressor  Discharge  Bleed  Flow 

DISFLW 

Airflow  Limit  Sv7itch 

AIRFLW 

FUlIL/ CONTROL 

' 

1 

\ 

Afterburni r Fuel  Flow 

A/B  FF 

\ 

Fan  Inlet  Guide  Vane  Position  ' 

IGV 

\ 

1 

Core  Variable  Stator  Position 

CVS 

i 

Jet  Nozzle  Throat  Area 

A8 

1 ' 

LUBRICATION 

i. 

Oil  Level 

LEVEL 

Oil  Pressure 

PRESS 

1 

Oil  Temperature 

TEMP 

Oil  Quality 

QLTY 

i 

Lube  Oil  Flow 

FLOW 

MECHANICAL 

Foreign  Object  Detector  Flag  #1 

FOD  1 

j 

Foreign  Object  Detector  Flag  #2 

FOD  2 

« 

I 

n-.rust  Bearing  #1  Condition 

BRNG  1 

4 

Thrust  bearing  irl  Condition 

BRNG  2 

Mass  Unbalance  Monitor  #1 

MUM  1 

j 

Mass  Unbalance  Monitor  #2 

MUM  2 

1 

Bearing  Race  Temperature  #1 

TEMP  1 

Bearing  Rf;ce  Temperature  #2 

TEMP  2 

li 

TABLE  4.2-1 

I I 
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A set  of  display  formats  were  generated,  based  on  the  informational  analysis  and 
display  philosophy.  These  formats  were  iterated  through  each  phase  of  the  program, 
with  Figure  4.2-2  depicting  a composite  format  sketch  based  on  Phase  IV  results. 

The  following  are  the  definitions  of  the  numeric  callouts; 

1-  Warning  Message  Area  - used  to  display  a summary  flashing  warning  message 
and  the  time,  in  seconds,  of  how  long  the  particular  situation  has  existed 

2-  Status  Bar  - constant  indication  of  engine  status  (normal,  marginal,  critical); 
summarized  into  4 sub-groups  including  all  of  the  monitored  engine  parameters 

3-  Critical  Bar  Graph  Display  - bar  graph  presentation  of  paraineters  which  have 
exceeded  critical  limits;  automatically  displayed,  provides  actual  numerical 
value  limit  value  for  the  parameter 

4-  Marginal  Bar  Graph  Display  - bar  graph  presentation  of  parameters  which  have 
exceeded  marginal  limits;  automatically  displays  and  provides  trend  infor- 
mation regarding  the  malfunctioning  parameter 

5-  Computer  Recommendations  - provides  pilot  with  computer  diagnosis  of  the 
problem  and  a step  by  step  procedure  for  corrective  action 

6-  Vertical  Scale  Display  - vertical  scale  presentation  of  "RPM"  or  "THRUST"; 
continuously  displayed  with  scale  differentiation  to  denote  which  parameter 
is  being  displayed,  and  a set  of  Indicil  and  acceptable  range  markers 

7-  Energy  Management  Display  - (not  shown)  summary  profiles  for  climb  and  cruise 
were  presented  in  the  lower  left  quandrant  of  the  display;  deleted  whenever  a 
malfunction  display  appeared 

A major  display  change  occurred  at  the  beginning  of  the  Phase  V effort.  This 
change  was  due  to  the  display  size  change  from  8"  x 10"  to  4"  x 5".  The  basic 
display  characteristics  STATUS  BAR,  HORIZONTAL  BAR  GRAPHS,  etc.,  did  not  change. 
However,  the  amount  of  information  presented  on  an  individual  format  was  reduced. 
Figure  4.2-3  is  a typical  format  representation  used  during  the  Phase  V effort  and 
indicative  of  future  formats  of  this  display  size. 
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Also  the  Phase  V effort  did  some  initial  formatting  of  pictorid.  displays 

as  shown  in  Figure  4.2-4.  A comparative  evaluation  was  conducted  of  the  pictorial 

versus  the  present  presentation 

4.3  EVALUATION 

The  previous  discussion  addressed  the  information  analysis  and  format  generation 
that  occurred  during  the  five  phases  of  the  lEIS  Program.  The  other  major 
task  area  of  concern  to  human  engineering  was  that  of  display  evaluation. 

This  effort  was  directed  toward  the  evaluation  of  the  lEIS  concept  and  associated 
display  formats  by  current  Navy  pilots. 

Initially  it  was  decided  to  conduct  two  evaluation  procedures.  One  was  a 
Dynamic  evaluation,  using  the  lEIS  demonstration  hardware  to  present  the 
scenario  in  a dynamic  mode.  The  other  a Static  Evaluation  with  the  scenario 
presented  by  means  of  Vu-graphs.  In  both  cases  the  pilot  subjects  were  observor s 
only  and  their  opinions  and  preferences  were  gathered  by  means  of  a questionnaire. 
The  questionnaire  addressed  the  following  display  considerations: 

• Display  characteristics  (size,  arrangement,  content,  etc.) 

• Status  Bar  concept 

• Manual  parameter  call  up 

• Automatic  fault  indication 

• Quantitative  versus  Qualitative  information 

• Energy  Management  Concept 

• Vertical  Formats 

Both  evaluation  procedures  were  run  with  the  Dynamic  Evaluation  conducted  at 
the  Naval  Air  Development  Center  at  Warminster,  Pennsylvania,  and  the  Static 
Evaluation  at  the  Naval  Air  Test  Center,  Patuxent  River,  Maryland  and  at  Oceana 
Naval  Air  Station,  Virginia.  A total  of  43  pilots  participated  in  the  evalua- 
tion exercise  and  24  of  them  completed  questionnaires. 
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The  second  evaluation  effort,  conducted  during  Phase  IV,  was  a "dynamic"  evaluation 
using  the  lEIS  demonstration  hardware  to  present  the  display  formats  and  a prepared 
questionnaire  to  record  pilot  opinion  and  preference.  This  evaluation  exercise 
was  conducted  at  the  Naval  Air  Test  Center,  Patuxent  River,  Maryland.  Nineteen 
Navy  test  pilots  participated  in  the  evaluation  and  sixteen  of  these  pilots  completed 
the  questionnaire. 

The  output  of  the  human  factors  effort  was  a set  of  display  format 
recommendations  which  were  based  on  the  analysis  of  the  questionnaire  responses. 
Generally  the  basic  display  formats  and  the  display  concept  appeared  to  be  satis- 
factory for  presenting  engine  status  information.  There  were,  however,  specific 
recommendations  for  format  modification,  they  were  the  following: 

• Continuous  Data  Display  - the  scales  should  be  modified  to  dif- 
ferentiate between  RFM  and  THRUST.  Also  a setting  indicator  and  "range  about  the 
setting"  should  be  added  to  the  vertical  scale  display. 

• Checklist  and  Procedures  - checklist  data  and  procedural  data 
display  should  be  a part  of  the  lEIS  presentation;  especially  complete  procedural 
information  for  corrective  actions. 

• Energy  Management  Display  - The  Phase  IV  scenario  presented  the 
energy  management  data  as  summary  type  information  only,  not  as  a "fly-to"  display. 

As  a summary  display  fuel  data  should  be  added  to  the  margin  information. 
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5.0 


CONCLUSICTiS  AND  RECOMMENDATIONS 


The  lEIS  studies  to  date  have  investigated  many  areas  of  technology 
related  to  the  definition  of  a baseline  system.  This  report  reflects  the  depth 
of  definition  of  each  element  of  an  Integrated  Engine  Instrument  System  which 
will  contribute  to  the  overall  AIDS  requirements. 

Specific  conclusions  and  recommendations  for  ISIS  relative  to  engine 
condition  monitoring,  system  design,  sensors,  and  displays/display  engineering 
are  presented  in  the  following  sections. 

5 . 1 Engine  Condition  Monitoring 

• An  appropriate  approach  to  engine  condition  monitoring  is  to  employ 

a computer  model  of  the  engine  thermod)mamic,  lubrication,  and  mechanical  systems. 

• A maximum  of  forty  five  engine  and  twenty  air  data  parameters  are 
deemed  necessary  to  adequately  monitor  the  condition  and  health  of  each  engine. 

• Oil  quantity  and  vibration  monitoring  along  with  horoscope  inspection 
are  found  to  be  three  of  the  most  effective  techniques  presently  used  for  detecting 
impending  engine  failure. 

• An  effective  approach  to  reduce  data  scatter  during  engine  monitoring 
is  to  sample  each  parameter  eight  times  over  a two  second  period  and  average  the 
readings  to  provide  a single  parameter  estimate. 

• Specifications  and  characteristics  of  software  for  performing  on  board 
engine  diagnostics  have  been  generated,  including  both  long  term  trending  and  fault 
isolation. 

• Transient  condition  monitoring  is  feasible,  but  extensive  development 
is  required  in  engine  modelling  and  sensor  transient  response  to  implement  this 
concept  (see  Volume  II,  Appendix  A). 

• For  lubrication/fuel  monitoring  systems  a reduction  in  size  of  Che 
Phase  V airborne  software  can  be  expected  using  techniques  found  satisfactory  in 
related  condition  monitoring  programs. 
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• The  Phase  III  gross  thrust  meter  availability  assumption  is  no 
longer  appropriate  since  no  work  has  been  undertaken  to  make  it  realistic.  An 
alternate  approach  to  obtaining  this  data  is  required  to  provide  an  effective 
thrust  display  for  lEIS. 

• Studies  should  be  undertaken  to  reduce  the  size  of  the  necessary  air- 
borne aerothermodynamlc  model  significantly  below  that  of  the  Phase  III  lEIS  study 
and  tailor  it  to  a candidate  engine. 

• Studies  should  be  undertaken  to  establish  the  extent  to  which  the 
lubrication/ fuel  airborne  software  size  can  be  reduced  and  tailored  to  an  lEIS 
candidate  engine. 

• Further  lEIS  studies  should  include  investigation  of  integration  of 
Digital  Electronic  Engine  Controls  and  transient  condition  monitoring. 

5.2  System  Design 

e An  overall  system  concept  for  lEIS  has  been  defined  and  is  sumiarized 
in  this  report. 

e The  total  lElS  memory  requirements,  in  terms  of  AADC  building  blocks, 
are  estimated  to  be  27. 5K  words  of  BORAM  and  16. 9K  words  of  RAMM.  These  BORAM 
requirements  amount  to  approximately  437.  of  a standard  AADC  BORAM  module.  Projected 
AADC  processor  utilization  time  is  1.37.. 

e A one  million  bit  data  recorder  with  a five  minute  loop  record  capa- 
bility when  an  engine  fault  occurs  will  be  required. 

a Analog  temperature  and  vibration  processing  is  not  reconsnended  because  of 
the  excessive  memory  size  and  processing  time  required  to  perform  these  functions 
digitally. 

e The  data  bus  transmission  rate  is  a maximum  of  40  KBPS.  Because  this 
bus  must  interface  with  other  A/C  systems,  it  will  probably  be  a MIL- STD- 1553 
command  response  type  bus. 
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• signal  conditioning  and  A/D  conversion  hardware  requirements  have 


I 


been  established  (see  Phase  III  for  details). 

e A comparison  of  computer  hardware  characteristics  has  been  made. 

• A modular  approach  to  signal  conditioning  circuitry  should  be 
investigated  so  that  lEIS  hardware  would  be  adaptable  to  various  aircraft  appli- 
cations. 

a Defining  a baseline  lEIS  system  (taking  into  account  the  AIDS  impact) 
is  recommended.  The  system  should  be  based  on  a specific  engine  and  could  be  used 
in  a simulator  and/or  flight  evaluation  program. 

5.3  Sensors 

• Pressure  sensors  currently  used  are  a strain  guage  and  a bourdon  type. 

• In  order  to  improve  pressure  sensing  accuracy  and  to  provide  digital 
outputs,  frequency  output  devices  such  as  piezo-electric  crystals  are  projected  as 
future  pressure  sensors. 

e Temperature  sensors  currently  used  are  thermocouples,  resistance 
temperature  detectors  (RTD) , and  optical  pyrometers.  ^ 

a Other  temperature  measuring  techniques  which  should  be  developed  are 
the  following; 

e Wall  Mounted  (non-immersion) 

# Resonating  Quartz  Crystal 

e Fiber  Optics  Harness  | 

e Improved  Optical  Pyrometers 

e Vibration  parameters  will  continue  to  be  sensed  with  piezoelectric 
accelerometers. 

e Flow  rate  measurements  are  made  using  fluid  drive  angular  momentum 
type  flow  transmitters. 

• Future  flow  devices  will  employ  fluidic  principles  to  obtain  volu- 
metric flow  rate  and  utilize  a density  measurement  to  calculate  mass  flow  rate. 
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• Position  sensors  presently  used  are  the  linear  variable  differential 
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(LVDT)  type. 

• Projected  future  position  sensors  will  be  magnetic  or  optical  digital 
position  sensors. 

• Speed  sensors  will  continue  to  be  the  variable  reluctance  and  eddy 
current  types. 

• Torque  motor  current,  which  is  pulse  width  modulated,  will  be  measured 
by  a timing  technique.  This  technique  is  the  current  standard. 

0 An  improved  oil  quality  measurement  technique  must  be  developed.  The 
most  promising  technique  is  to  measure  the  magnetic  debris  in  the  lube  oil. 

• Thrust  is  perhaps  the  most  difficult  engine  performance  parameter  to 
measure  directly  in  an  airborne  situation.  The  accuracy  of  indirect  measurements, 
which  require  sensing  nozzle  static  pressure  and  throat  area,  must  be  inproved 
significantly  to  obtain  desired  thrust  accuracy. 

e A UV  tube  with  an  electronic  interface  system  is  the  accepted  standard 
device  for  detecting  afterburner  liftoff.  For  the  future,  smaller,  more  rugged, 
and  higher  temperature  range  UV  detectors  should  be  developed. 

5.4  Displavs/Pisplay  Engineering 

e A comparison  of  candidate  display  devices  indicates  that  a monochrome 
CRT  best  meets  the  requirements  of  lEIS. 

• Significant  improvements  in  bri^tness  problems  and  circuit  complexity 
problems  of  penetration  type  color  CRT's  must  be  made  before  consideration  could  be 
given  to  them  for  this  application. 

e A 5"  X 7"  viewing  surface  is  recommended.  However,  displays  can  be 
adapted  to  other  sizes,  for  example  the  4"  x 5"  Phase  V display. 

• Minimum  character  size  is  3/16  inch  and  minimum  resolution  is  a 256  x 
320  dot  matrix  equivalent. 
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• Average  power  is  less  than  100  watts. 

• Brightness  is  greater  than  100  foot  lamberts. 

• Contrast  ratio  is  2:1  in  10,000  foot  candles  ambient. 

• MIBF  is  greater  than  3000  hours. 

• A slight  edge  is  given  to  the  raster  scan  mode  of  display  generation 
due  to  simple  scan  and  drive  circuitry. 

• The  recommended  approach  to  display  generation  using  AAOC  modules 

is  to  employ  a dedicated  PMU  and  TM,  which  would  operate  from  a coded  display  list 
stored  in  TH. 

• For  certain  parameters  human  factors  display  evaluations  utilizing 
pilot  subjects  have  shown  that  the  lEIS  display  concepts  and  formats  are  satisfactory 
for  engine  status  monitoring. 

e Pictorial  displays  appear  to  be  a possible  alternative  display  technique, 
however  further  Investigation  and  evaluation  are  required. 

• The  energy  management  formats  have  to  be  modified  and  expanded  to 
present  more  "capability"  type  information,  e.g.  fuel  management. 

• The  procedure/checklist  type  information  has  to  be  expanded  to  cover 
all  mission  aspects. 

• Consideration  should  be  given  to  the  continuous  display  of  additional 
parameters,  especially  fuel  flow. 

s Some  recommendations  regarding  data  deletion  and  reorientation  are 
reflected  in  the  proposed  lEIS  formats  as  shown  in  Appendix  D. 

e Dynamic  evaluations  of  the  lEIS  displays  should  be  undertaken.  A 
simplified  engine  model  could  be  developed  for  this  purpose. 

e The  lEIS  effort  to  date  has  not  specifically  addressed  the  engine 
display  requirement  posed  by  VSTOL  operation.  In  particular  the  area  of  thrust 
vectoring  displays  for  all  flight  phases  should  be  Investigated. 
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• Based  on  the  results  of  the  limited  Phase  V evaluations  of  color 
coded  displays,  which  indicated  distinct  advantages  in  display  interpretations, 
we  reconraend  that  the  future  human  factors  activities  include  more  color  evaluation. 
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